- - Revision 2.59 - This is an obsolete unmaintained copy of the style guide. - Please use pyguide.md instead. - -
- -- Each style point has a summary for which additional information is available - by toggling the accompanying arrow button that looks this way: - . - You may toggle all summaries with the big arrow button: -
-- Python is the main scripting language used at Google. This - style guide is a list of dos and don'ts for Python - programs. -
- -- To help you format code correctly, we've created a settings - file for Vim. For Emacs, the default settings should be fine. -
- - -string module
- where possible. Use function call syntax instead
- of apply. Use list comprehensions
- and for loops instead of filter and
- map when the function argument would have been an
- inlined lambda anyway. Use for loops instead of
- reduce.
- .py files do not need to start with a
- #! line. Start the main file of a
- program with
- #!/usr/bin/env python with an optional single digit
- 2 or 3 suffix.
- object. This also applies to nested classes.
- format method or the % operator for
- formatting strings, even when the parameters are all strings. Use your
- best judgement to decide between + and %
- (or format) 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_CONSTANT_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.59 -
- - - - Amit Patel