Hacker News Reader

Comment by publicfig | Hacker News Reader

Nice to see some movement away from the 79 character limit. I've had to make some incredibly unreadable code in the past just to comply with it.

View on HN

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.

I read a lot of code. Links from Twitter to interesting projects, peeking at pull requests while I'm away from my computer, etc.

I read a lot of code.

Guido just proposed a patch that undoes this change and restores the old 79 character limit...

http://bugs.python.org/issue18472#msg194089

--- a/pep-0008.txt

+++ b/pep-0008.txt

@@ -159,12 +159,11 @@

Maximum Line Length

-------------------

-Aim to limit all lines to a maximum of 79 characters, but up to 99

-characters is acceptable when it improves readability.

+Limit all lines to a maximum of 79 characters.

EDIT: formatting/description

The full patch also includes this:

  +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).
  +

https://codereview.appspot.com/12269044/patch/1/1001

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.

I couldn't figure out if they have that dumb indentation rule.

https://gist.github.com/radiosilence/6133713

I mean how can anyone say that the former is better than the latter?

Either is acceptable per PEP 8.

Oh, neat! I don't have to feel dirty now.

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.

I don't think of it as a new limit at 99 chars, meaning you should switch, but that the 79 limit isn't a hard limit, just a guideline.

If you have a line that would suffer under 79 chars, let it go a little long, but no farther than 99.

Anyone changing their editor settings based on the new guidelines?

In vim, I'm thinking about using:

    set colorcolumn=79
    set textwidth=99

Even the old PEP8 was stating:

    When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.

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.

Edit: Glad to see that section might get an update http://bugs.python.org/issue18472#msg194086

Edit2: Gudio van Rossum proposes a patch https://codereview.appspot.com/12269044/diff/1/pep-0008.txt

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.

Unable to edit this any more, but the patch has been applied http://bugs.python.org/issue18472#msg194144

My N=5 anecdote is the opposite; people who respect that limit have better looking - and simpler - code then those who don't.

There's a reason newspaper stories are in columns.

Agreed. Text of the revised recommendation:

> Aim to limit all lines to a maximum of 79 characters, but up to 99 characters is acceptable when it improves readability.

Nobody ever specifies whether or not 0x0a counts towards their limit.

http://i.imgur.com/LypKK8I.png

The reason it's 79 instead of 80 is to allow for at least one funky glyph at the end of the line since many editors do that kind of thing.

No, its so a diff looks good (with < or > lines in the first column)

edit: you're correct, that's the rationale in the pep. It's not why I stick at 79 though, I do it for git log -p, etc.

That's between lines, isn't it?

OTOH, 0x0d definitely counts toward the limit!

Take it away and there is no line, just a text fragment: /bin/echo -n and then

In other words, it's a line ending, not a line separator.

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.

"ignore = E501" is easy, free productivity and maintainability boost.

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.

Reply on news.ycombinator.com