I disagree, but only as of about 2 months ago. For awhile I stuck to 79 cols but understood if people elsewhere wanted to move to 100 or 120.
I've changed my mind because I've started doing a lot of code-reading on my phone. It's got a big screen (Galaxy S3) but even still, 80 columns is the perfect width to fit all the code on my screen without needing to scroll.
What's old is new again. We went from tiny monitors to huge monitors and now we're back to tiny "monitors" again. Anywhere where I am able to make the determination, 79 columns will be the standard.
Just curious: why are you reading code on your phone? I've heard of doing basic web-dev stuff via mobile (using stuff like Diet Coda) but rarely anything else.
+Some teams strongly prefer a longer line length. For code maintained
+exclusively or primarily by a team that can reach agreement on this
+issue, it is okay to increase the line nominal line length from 80 to
+100 characters (effectively increasing the maximum length to 99
+characters), provided that comments and docstrings are still wrapped
+at 72 characters.
+
+The Python standard library is conservative and requires limiting
+lines to 79 characters (and docstrings/comments to 72).
+
Good point, didn't see that. It's interesting how clearly it differentiates between core CPython style and 3rd party style. I'm guilty of thinking of PEP8 as the definitive general style guide. But this not what it claims to be- it's just the core development style guide. So it's reasonable for it to be a bit conservative while saying, this is a hardline stand that you may want to deviate from.
What? There's no proscription against either of those. However a little common sense would go a long way in your first example. Break at spaces/hyphens/other natural break points in strings. Also the + symbols aren't necessary. String continuation is implicit inside parentheses.
I always stick to 79 chars and stick to the latter method for indentation. I am completely happy with the readability of my code as a result. Thus, I'm not really happy with the new 99 char rule.
Thing is the code will also become less readable for many people if your line is longer than 79 chars. My terminals have a fixed width so that they fit perfectly side by side on my multiple monitors. Using random higher numbers just means that I have to use random window sizes and what not.
Yeah, I could have 300 char wide terms, or 600 if I really wanted to. There was a reason for 79. There isn't for 99.
Thanks for pointing that out. Also, the second link, being a perfectly clear and readable side-by-side diff is exactly the reason why 79 chars is important.
I've always used my best judgement. It's a peeve of mine that devs stick to that as a hard-and-fast rule, even when you're 1 or 2 characters over, and apply some crazy indent structure just to get past it.
While we're at it, can we ditch the convention of indenting arguments to line up with the method name? A single tab per-nested level will do.
I'm in two minds. I prefer not to have to have everything too wide, as that messes up running editors side-by-side and for viewing side-by-side diffs.
I think I'm fine with it provided that readability doesn't suffer if my editor or viewer wraps line >79 characters. I don't want to be forced to make everything wider to see that extra readability. But if making it wider makes it more readable even if my editor wraps the line, then that makes sense.
