From f900c2c70d4ece7e0f4cf3576ee85ef9f1264c08 Mon Sep 17 00:00:00 2001
From: "apicard@google.com"
+
+ Revision 2.12
+
+ Each style point has a summary for which additional information is available
+ by toggling the accompanying arrow button that looks this way:
+
+ Python is the main scripting language used at Google. This
+ style guide is a list of dos and don'ts for Python
+ programs.
+ Google Python Style Guide
+
+ Antoine Picard
+ Eugene Jhong
+ Jeremy Hylton
+ Matt Smart
+ Mike Shields
+
+ Overview
+ Important Note
+ Displaying Hidden Details in this Guide
+
+
+ This style guide contains many details that are initially
+ hidden from view. They are marked by the triangle icon, which you
+ see here on your left. Click it now.
+ You should see "Hooray" appear below.
+
+
+
+
+
+ Background
+ Python Language Rules
+
+ pychecker
+
+
+ Run pychecker
over your code.
+
+
+
+
+ Imports
+
+
+ Use import
s for packages and modules only.
+
+
+
+
+ Packages
+
+
+ Import and refer to each module using the full pathname location of
+ that module.
+
+
+
+
+ Exceptions
+
+
+ Exceptions are allowed but must be used carefully.
+
+
+
string
module where
+ possible.
+
+ #!/usr/bin/env python<version>
+
+ object
. This also applies to nested classes.
+
+ %
operator for formatting strings,
+ even when the parameters are all strings. Use your best judgement
+ to decide between +
and %
though.
+
+ TODO
comments for code that is temporary, a
+ short-term solution, or good-enough but not perfect.
+
+ property
to keep the syntax consistent.
+
+ module_name, package_name, ClassName, method_name, ExceptionName,
+ function_name, GLOBAL_VAR_NAME, instance_var_name,
+ function_parameter_name, local_var_name.
+
+ + BE CONSISTENT. +
+ ++ If you're editing code, take a few minutes to look at the code + around you and determine its style. If they use spaces around + all their arithmetic operators, you should too. If their + comments have little boxes of hash marks around them, make your + comments have little boxes of hash marks around them too. +
+ ++ The point of having style guidelines is to have a common vocabulary + of coding so people can concentrate on what you're saying rather + than on how you're saying it. We present global style rules here so + people know the vocabulary, but local style is also important. If + code you add to a file looks drastically different from the existing + code around it, it throws readers out of their rhythm when they go to + read it. Avoid this. +
+ + + ++Revision 2.12 +
+ + + + Amit Patel