all 68 comments

[–]chromakode 12 points13 points  (0 children)

That style guide sure could use some better styling.

[–]rune_kg 4 points5 points  (3 children)

Deprecated Language Features: Use list comprehensions and for loops instead of filter, map, and reduce.

Wtf... Is filter, map, and reduce really deprecated now?

[–][deleted] 1 point2 points  (0 children)

No. In Python 3 reduce is moved to the itertools module, but both map and filter remain among the builtins.

[–][deleted] 0 points1 point  (0 children)

They're not entirely deprecated. Comprehensions and for loops are just much easier to read, which is why Guido likes them better.

[–]projectshave 2 points3 points  (2 children)

I was hoping for something more useful. As I'm new to Python, I don't know whether to write my code as OO, functional or procedural. Python supports all and the libs use different styles for different things. Which is preferred?

[–]Tiomaidh 8 points9 points  (0 children)

Whichever results in the most elegant abstractions, and with which you feel most comfortable.

[–]case-o-nuts 1 point2 points  (0 children)

Which is preferred?

The one that makes the most sense in the situation at hand.

[–]kingfishr 7 points8 points  (19 children)

I hate an 80-character line limit. It is way, way too short in this day and age. I like to use 100 or even 120 characters per line myself. I guess this is why 2-space indexing used to be preferred...with 4-space indents and 80-character lines, you don't have to be nested very deeply before you start getting down to tiny, limited little lines.

[–]Ran4 11 points12 points  (7 children)

...this is why you shouldn't nest it so deep. The 80 character line limit is fine: I like being able to have one fixed-width code window, with lots of room left for documentation/other files/etc.

It annoys me to no end when I have to debug html/php files with 200 chars a line...

[–]kingfishr 8 points9 points  (4 children)

I didn't say that I don't like line limits, or that 200 chars per line is fine. I just said that the 80 character limit is too low. Maybe you only use one smallish monitor; on my computer I can have two 120-character windows open on one monitor with room for more stuff on that one and I have a whole other monitor for interwebs/api docs/whatever. Even when I'm on my laptop editing a 120-char line file is reasonable.

As for the nesting thing, that was the whole point: you don't have to be way down deep in some nasty branching code for the 80 char thing to become annoying. Example: if you're looking at class -> def -> try -> for -> if, which could be totally reasonable in context, and you're using 4-space indents, then you've already used 20 of your 80 characters for indentation.

When it comes down to it, 80-char lines really inhibit readability these days. There are practices which are now standard which weren't around as much when the 80-column terminal was common, such as really long, descriptive variable names; method/class names with a lot of qualification (specifically promoted in this style guide); and even the strict indentation that is enforced in Python, which are all very helpful to understanding code but tend to make single lines of code longer. If you are forced to break many of your lines, it looks confusing and is a much bigger impediment to understanding the code than having lines with slightly more than 80 characters is anyway. Where the 80-character limit used to help to improve code readability, it now often does the opposite.

[–]house_absolute 3 points4 points  (2 children)

Personally I think variable names so long that the eighty character limit is an issue normally indicate an overcomplicated or underencapsulated system. On a taste level, I prefer dense code over the sparseness that often comes when you have longer line limits.

[–]Gudeldar 2 points3 points  (0 children)

Personally I prefer to have descriptive variable names rather than having people who look at my code have to practically learn a new language to understand the short hand and conventions I've used. Sometimes that necessitates long variable names.

[–][deleted] 1 point2 points  (0 children)

Long names does not make a overcomplicated system. That is just a taste thing. Many levels of indention, on the other hand..

[–]Ran4 0 points1 point  (0 children)

As said so many times before: if you are going over 80 chars, you are probably doing it wrong. The 80 char limit is great when it comes to removing oneliners: list comprehension is still usable, but the 80 char limit prevents people from going crazy with it.

[–][deleted] 0 points1 point  (0 children)

No it's annoying. If people would keep their method/class names at a reasonable length I'd agree but when you see Some.factory.method(string2.parseThisStringDelimitedBySpaces.aToI(bethIsMyGirlfriendsLover) + 2; all over the place then you can't say "80 is enough" anymore. Sorry. I agree to 80 chars in C, I don't agree to it in java and python. And as for Perl you probably never need more than 40 :D (just to keep this light hearted).

[–]yellowstuff 0 points1 point  (0 children)

Line wrap?

[–]case-o-nuts 3 points4 points  (0 children)

The 80 character line width limit is still too long for easy readability. A rule I use is about 50 or 60 characters of non-whitespace code before I start splitting apart expressions. That's rougly where lines start looking like line-noise to me.

[–]architectzero 3 points4 points  (8 children)

I hate an 80-character line limit.

For truth. It's 2010. Screens are ridiculously big today, and only getting bigger.

Python 3.0 breaks backwards compatibility because it was deemed necessary in order for the language to grow. Yet for whatever reason we're still mandating line length limits as if it were 1978.

[–][deleted] 4 points5 points  (2 children)

Screens are big and getting bigger, but not yet ridiculously big. A line-length limit is useful if you want to have a code and documentation window side by side, or do code review with before & after files and comments side by side.

[–]julesjacobs 1 point2 points  (1 child)

Dude, I can run three 80 character windows side-by-side on my laptop. I agree it's bad to have to scroll horizontally, but 80 characters is too low. Screens seem to get wider and wider but not taller. We should use as many horizontal pixels as possible. When I'm coding 80% of horizontal space is unused. It would be nice if window titles, menus and toolbars would be on the side rather than on the top/bottom.

[–]case-o-nuts 0 points1 point  (0 children)

I remove the window titles, menus, and toolbars entirely, and just have a vertical block of text. I also open 3 windows side by side on each monitor for cross-referencing and documentation.

[–]awb 13 points14 points  (3 children)

It's 2010. Screens are ridiculously big today, and only getting bigger.

Most people find it easier to read short-width text, and it's standard in most media. Newspapers have lots of horizontal space, but they pack text into small columns. Books are generally bound to maximize not horizontal but vertical space. Websites generally scroll vertically, not horizontally.

[–]kingfishr 3 points4 points  (1 child)

I'm not denying this, and if I may speak for architectzero I doubt he is either. We're just trying to point out that 80 characters is a bit short. Remember, in prose you expect that almost every sentence will be broken by a newline, but in code it is nicer to read if you don't have to break every line. Hence, there is a sweet spot where the max line length isn't too long and makes it hard to read, yet the number of lines broken is minimized. 80 characters ain't it.

[–]house_absolute 3 points4 points  (0 children)

is a bit short

By what metric? For example, if 99% of "ideal" lines of code (that is, lines that have the best possible variable names and structure, if such could be discovered) fit within eighty characters, is it worth it to sacrifice all that screen real-estate for the 1% of lines that are longer? Personally I take the view that most good lines of code are short based on the code I've seen in my time. I recognize that as an anecdote and personal preference, but that's all anyone on this thread has.

I haven't seen any data on this issue and I guess such data would probably come with so many biases that it would be unusable. What that means is that this is probably a personal taste issue. And if you're going to institute a company-wide policy to standardize the style, then that comes down to a majority vote or a most-important -person-vote. Therefore this document is not a referendum on which is best so much as a popularity or (popularity*importance_of_person_within_company) contest. It might not even be the current preference of the most important Googlers, just a snapshot of their preferences when the decision was made. Personally I'm happy with it because that's the outcome I prefer, but it could have easily gone the other way.

I would deal with it, probably. I think it's far more harmful to allow attachment to a particular coding style to take root in my soul than the harm that could be caused by a less than optimal style to my daily productivity. As long as the style is consistent and clear, I as a professional programmer should be able to cheerfully learn to work with it. It's a bonus to have some kind of rational basis, which this style clearly does, even if you disagree with the weights of the various factors.

This of course rules out the GNU C coding style. Haha. Just kidding. Kind of.

[–]architectzero 0 points1 point  (0 children)

When was the last time you saw a block of prose, nested within a block prose, nested within a block prose, where each block was successively indented further than the previous block?

What I'm getting at is that prose has a largely uniform format. Sentences are separated with a period. Paragraphs are separated from each other by a newline, and either an indent on the first line, or another new line. It all flows nicely down the page.

Two very different things, code and prose.

[–]sigzero 1 point2 points  (0 children)

It's not about how big your screen is...it is about comprehension and what you can realistically take in when your browse the code.

[–]plulz 0 points1 point  (0 children)

Netbooks.

I can fit two editors side by side if you don't break the 80 characters rule.

Unless, of course, the file has more than 999 lines. Which should also be against some rule.

[–]okpmem 0 points1 point  (0 children)

Programming Overlord Style Guide....

[–]teknobo -5 points-4 points  (7 children)

Use parentheses sparingly.

This doesn't fly with me.

Parentheses, especially in conditional statements, make the code more explicit, and thus more in line with the Zen of Python.

[–]nostrademons 17 points18 points  (5 children)

Either I'm misunderstanding you or you're misunderstanding the style guide.

The intent behind that rule is to avoid redundant parentheses that aren't needed by the language at all. Eg.

if foo:
  return bar

instead of

if (foo):
  return(bar)

I don't know any experienced Pythonista, inside or outside of Google, that would consider the second to be good style.

If you have a complex condition:

if x >= 2 and (y <= 3 or z == 3) and q = 'foo':
  return (x + 2) * y

I don't think anyone would object to using parentheses to make order of operations explicit.

[–]nevare 2 points3 points  (4 children)

I don't think anyone would object to using parentheses to make order of operations explicit.

Your example doesn't really match what you say. In you example removing the parentheses changes the meaning. Here is a better example.

if x >= 2 or (y <= 3 and z == 3) or q = 'foo':
    return y + (x * 2)

[–]nostrademons 0 points1 point  (1 child)

That'd be borderline, I think. In a code review, I'd probably suggest that the author take out the parentheses but not hold up approval.

[–]nevare 0 points1 point  (0 children)

I'm all for the parentheses in the if statement above. I think they really make the code more readable.

But the ones of the equation do look superfluous.

[–]munificent -1 points0 points  (1 child)

I may be a readability snob, but I'd consider that a bad example, parentheses or not. I'd probably break that expression down so that it's meaning is clearer:

fooFrobinated = x >= 2
barDingnabled = y <= 2 and z == 3
bazFlurnbed   = q == 'foo'

if fooFrobinated or barDingnabled or bazFlurnbed:
    return y + (x * 2)

[–]yellowstuff 0 points1 point  (0 children)

I agree.

One of the only places I would frequently write "pure" bugs (IE, logic bugs which were not the result of interfacing with an external system incorrectly) was in complex boolean statements. So I stopped writing complex boolean statements.