Re: Standardizing our Python code style

Julian Foad wrote:
> Blair Zajac wrote:
>> We've got a bunch of different Python styles in our code, and as we have a C
>> coding style, I'd like to propose we standardize the Python code using the style
>> guide at python.org so we don't have to switch between different styles in the
>> project:
>>
>> http://www.python.org/doc/essays/styleguide.html
>> http://www.python.org/dev/peps/pep-0008/
>> http://www.python.org/dev/peps/pep-0257/
>
> To get us started, can you summarize the top few inconsistencies, and
> which way we should do each of those things? +1 on consistency, +1 on
> following the commonly used style guides, but -1 on everyone having to
> digest the complete style guides before making their next patch.

The largest inconsistency is 2-space versus 4-space indentation, where 4-space
is the standard. If you're short on time, just read PEP-8, don't bother with
the other one.

The major ones, in my opinion from PEP-8 are the following:

Indentation

     Use 4 spaces per indentation level.

   Tabs or Spaces?

     Never mix tabs and spaces.

   Maximum Line Length

     Limit all lines to a maximum of 79 characters.

Imports

     - Imports should usually be on separate lines, e.g.:

         Yes: import os
              import sys

       Imports should be grouped in the following order:

       1. standard library imports
       2. related third party imports
       3. local application/library specific imports

   Pet Peeves

     Avoid extraneous whitespace in the following situations:

     - Immediately inside parentheses, brackets or braces.

       Yes: spam(ham[1], {eggs: 2})
       No: spam( ham[ 1 ], { eggs: 2 } )

     - Immediately before a comma, semicolon, or colon:

       Yes: if x == 4: print x, y; x, y = y, x
       No: if x == 4 : print x , y ; x , y = y , x

     - Immediately before the open parenthesis that starts the argument
       list of a function call:

       Yes: spam(1)
       No: spam (1)

     - Immediately before the open parenthesis that starts an indexing or
       slicing:

       Yes: dict['key'] = list[index]
       No: dict ['key'] = list [index]

     - More than one space around an assignment (or other) operator to
       align it with another.

       Yes:

           x = 1
           y = 2
           long_variable = 3

       No:

           x = 1
           y = 2
           long_variable = 3

   Other Recommendations

     - Always surround these binary operators with a single space on
       either side: assignment (=), augmented assignment (+=, -= etc.),
       comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
       Booleans (and, or, not).

     - Use spaces around arithmetic operators:

       Yes:

           i = i + 1
           submitted += 1
           x = x * 2 - 1
           hypot2 = x * x + y * y
           c = (a + b) * (a - b)

       No:

           i=i+1
           submitted +=1
           x = x*2 - 1
           hypot2 = x*x + y*y
           c = (a+b) * (a-b)

     - Don't use spaces around the '=' sign when used to indicate a
       keyword argument or a default parameter value.

       Yes:

           def complex(real, imag=0.0):
               return magic(r=real, i=imag)

       No:

           def complex(real, imag = 0.0):
               return magic(r = real, i = imag)

     - Object type comparisons should always use isinstance() instead
       of comparing types directly.

         Yes: if isinstance(obj, int):

         No: if type(obj) is type(1):

     - For sequences, (strings, lists, tuples), use the fact that empty
       sequences are false.

       Yes: if not seq:
            if seq:

       No: if len(seq)
           if not len(seq)

     - Don't compare boolean values to True or False using ==

         Yes: if greeting:

         No: if greeting == True:

         Worse: if greeting is True:

     - Comparisons to singletons like None should always be done with
       'is' or 'is not', never the equality operators.

Blair

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410333
Received on 2009-10-22 19:58:20 CEST