URL: http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm
After reading Matt Harrison's notes about Python at Google I noticed something which I couldn't add up.
"Python programmers at Google must follow a strict style guideline (based on PEP8 with 2 spaced indenting). When engineers are first granted commit access to their SCM system, they must pass a style test."
"based on PEP8" but rejecting such an important part as indentation really is.
From PEP 8 Style Guide for Python Code
"Use 4 spaces per indentation level."
All Python code from Google Code uses 2 spaces (not tabs) and that's not what Guido uses or recommends.
I know this is an anal issue to nag about but I was modifying some code today that uses 2 spaces and I just think it's more difficult to scan. Look at this Google code for example (from GTags):
def read_quoted_string(sexp, preserve_backslashes = 0):
retval = ''
i = 0
while sexp[i] != '"':
i = i + 1
i = i + 1 # skip opening "
while sexp[i] != '"':
if sexp[i] == '\\':
i = i + 1 # skip over \
if preserve_backslashes:
retval += '\\'
retval += sexp[i]
else:
retval += sexp[i]
i = i + 1
return (i, retval)Compared to the same code but formatted according to PEP 8:
def read_quoted_string(sexp, preserve_backslashes = 0):
retval = ''
i = 0
while sexp[i] != '"':
i = i + 1
i = i + 1 # skip opening "
while sexp[i] != '"':
if sexp[i] == '\\':
i = i + 1 # skip over \
if preserve_backslashes:
retval += '\\'
retval += sexp[i]
else:
retval += sexp[i]
i = i + 1
return (i, retval)Notice how the Google code also formats their parameters:
(sexp, preserve_backslashes = 0)And again, this is what PEP 8 says on the subject:
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)Why Google? Why can't you adhere to the more readable PEP 8 now that you've started sharing your code on Google Code
Comments
Post your own commentI use 2 also, I've never had any problems - it cuts down on heavily nested items running really far to the right.
Anyways, it seems like this would be easy to fix with a script that changes " <char>" to " <char>" at the start of a line in each file within a directory?
Err, thats obviously 2-spaces-then-a-char changed to 4-spaces-then-the-char. Damn you html :(
Of course if you go by Linus' rules, if you've indented that far, you should have a function.
Heavily nested things are a design problem in you application...
I started off using 2 spaces, then changed to 4 spaces when I started working in a team. Four spaces is much more legible and makes it a hell of a lot easier to scan read!
Well, since the BDFL works at Google, I suppose they could be up on the issue. Ultimately, it is what works. Who knows? Maybe they are so looped and indented that they are running against PEP8 length of line issues.
One big bonus is that by having all the "work" code using 2 spaces, you can keep your good code (the hacks with 4 space indentations) separate from the lesser indented "good enough for work" code.
Google code is icky :-)
I'd write it as so, optionally using .append() and ''.join()... and .find('"')
def rqs(sexp, preserve_backslashes=False):
retval = ''
i=0
while sexp[i] != '"':
i += 1
i += 1
while sexp[i] != '"':
c = sexp[i]
if c != '\\' or preserve_backslashes:
retval +=c
i += 1
return (i, retval)
their version doesn't seem to work right when the input ends in \", unless it isn't supposed to :-)
minimally, the
retval += sexp[i]
else:
retval += sexp[i]
is redundant...
(select post+right click+view selection source will fix indentation :-)
Based on doesn't mean the same as, so they can have a policy based off of, but not the same as PEP 8. I'd be more concerned about the inconsistent usage of +=, personally.
Actually, it's not really that great code regardless of the indentation, if you think about it.
In my experience, the notion of readability just depends on what you're used to. I've worked for long periods of time with codebases at 2, 4 and 8 spaces per tab. Switching from one to the other is always difficult, and your first impression is usually a bad one, but that soon goes away. Same thing with different bracketing styles in lesser languages.
My only real gripe with 2-space indenting is it may encourage some coders to write heavily nested code, which I find unreadable for reasons of control-flow complexity rather than formatting.
Very good point. It's a matter of habit. More so than beauty and what Google is doing is great in that they enforce unity. Just a shame that unity is 2-spaced :)
Like Linus said (speaking of 8-space indents!), if your code is scrolling too far to the right because of the indent level, that's a sign you should be refactoring, not a sign you need to use less spaces to indent with. :)
I never understood the aversion to just using single-characters TABS that you can set your editor to show as whatever number of spaces...
If you're nesting that much, you're doing something wrong :-)
2-space indent makes sense because you can fit more on one line. Ie there will be fewer cases where you'll need to break a statement across multiple lines. Makes it easier to stay within an 80 char limit so I can fit either 2 text editing windows or a browser and a text editor side-by-side.
It's takes a little bit to adjust to but after working in python and javascript (also 2-space indent) scanning code with 4-space indenting is awkward now.
If I was writing C# code in Visual Studio or MonoDevelop where the IDE generally takes up a whole screen then I would definitely be using 4-spaced indent. I think spacing is such a religious topic because preferences depend on context and subjective taste.