10 ms·

Shorter lines are easier for the eye to visually scan without accidentally skipping up or down during the leftward return saccade.[1] 80 characters happens to

Shorter lines are easier for the eye to visually scan without accidentally skipping up or down during the leftward return saccade.[1] 80 characters happens to be just a little longer than the supposedly ideal measure for continuous text promulgated by Robert Bringhurst.[2] I take the even more draconian approach of wrapping to 72 columns when writing comments, after the fashion of PEP 8.[3] Of course, Linus will dictate the style of his projects' codebases as he deems fit. [1]https://en.wikipedia.org/wiki/Saccade https://en.wikipedia.org/wiki/Saccade [2]http://webtypography.net/2.1.2 http://webtypography.net/2.1.2 [3]https://www.python.org/dev/peps/pep-0008/#maximum-line-length https://www.python.org/dev/peps/pep-0008/#maximum-line-lengt...

coldtea 5y ago
Even PEP8 says "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 length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters."
- indymike 5y ago
  > it is okay to increase the line length limit up to 99 characters PEP8 is strongly biased towards making code readable, and has helped a generation of programmers start thinking about readability when coding. The line length limit, though, is one of the few parts of PEP8 that introduced defects as a practice. Holding to 80 characters causes: * string concatenation bugs from breaking up long strings * errors in expressions broken up into multiple expressions just to fit * bias to use shorter variable names My favorite part of PEP8 was the warning about "foolish consistency".
  - unixhero 5y ago
    Are we supposed to be reading the PEPs?
    - novok 5y ago
      If you care about the reasoning behind whatever feature they are implementing.
- GoblinSlayer 5y ago
  Comments suffer even more from line length limit. I saw it many times when a comment is changed and then all following lines get rewrapped.
Diggsey 5y ago
- Code is not prose. It's not read like a book so it's not clear that an "ideal measure for continuous text" is at all relevant. - Most lines are short even if the limit is more than 80 characters, so you're unlikely to accidentally shift up or down after reading a long line. - Even if there turns out to be some benefit for reading code based on Saccades, that means nothing unless you can make some quantitative comparison with the other advantages and disadvantages of a longer line length.
- throwawayboise 5y ago
  For me it's not just the length of the line but the level of indentation. I think wide indents are good for readability, so if you're using standard tabs and also sticking to 80 columns as a hard limit then you have only 64 characters to work with at two levels of indentation. Excessive indentation is a clue that you may want to refactor, but two levels is pretty common. 80 charcters starting at the point of indentation is more reasonable. At two levels of indenting, you might get out to 96 characters, which still fits comfortably in most GUI terminal windows.
  - AlphaSite 5y ago
    W is the bare minimum, it’s a function and a conditional or loop, 3 or 4 is pretty common.
- xxpor 5y ago
  The biggest problem with short lines isn't even the line length, it's that it encourages stupid variable names in order to keep things on one line. Silly abbreviations that no one new to the code can figure out are the bane of my existence.
- lgrapenthin 5y ago
  Why does code have to be "read like a book" to be considered "continuous text"? Of course code is continuous text.
  - tasogare 5y ago
jagger27 5y ago
> I take the even more draconian approach of wrapping to 72 columns when writing comments, after the fashion of PEP 8.[3] Which also happens to be how Linus wrapped the lines of this particular email.
- SonOfLilit 5y ago
  Plaintext email is wrapped to 72, that's in the RFC - Linus didn't have much choice there.
  - rhn_mk1 5y ago
    Sure did: > Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 https://www.arp242.net/email-wrapping.html https://www.arp242.net/email-wrapping.html
coldtea 5y ago
That's for books. When reading code, I'd rather see a single statement on one line, rather that break it at 2 lines because it passed some ancient 80 char limit...
- d0mine 5y ago
  "ancient" doesn't mean wrong. Round wheels are ancient, it doesn't mean we should switch to the square wheels.
  - cortesoft 5y ago
    It doesn't mean right either, and the person you are responding to gave specific reasons why they prefer longer.
    - kortilla 5y ago
      So it’s almost as if the “ancient” qualifier was useless.
      - cortesoft 5y ago
        Well it was clearly meant to imply that the reason we are using it is merely tradition, and that there was a reason a long time ago that no longer applies.
      - coldtea 5y ago
        It was intended to mean "relavent in old times".
  - coldtea 5y ago
    >Round wheels are ancient, it doesn't mean we should switch to the square wheels. No, but it means we better use rubber wheels, not stone ones...
  - hsbauauvhabzb 5y ago
    We also shouldn’t burn people deemed witches at the stake. Being ancient doesn’t make it right, either.
weego 5y ago
1) has tenuous relevance at best 2) The 80 or 66 char or whatever is literally a non-science driven designer rule of thumb that's actually the opposite conclusion from results of actual research into the issue (granted it's not exactly a deeply studied niche but there is research).
phil294 5y ago
When "visually scanning" code, in 90% of the cases, only the first 10 characters matter anyway, so I fail to see your point. How often do you really need to grasp, say, all function arguments at once?
michaelcampbell 5y ago
These opinions about readability "flow" using numbered footnotes strikes me as the height of irony, but that's me.
lobocinza 5y ago
Arbitrary line breaking is ugly and a unnecessary source of errors. I avoid writing lines longer than 80 chars but in some cases it feels better and more ergonomic/readable to exceed it.
dan-robertson 5y ago
I think I heard somewhere that the studies about line length don’t actually give very strong evidence in favour of short lines. On the other hand, I don’t have a source for that. Do you know if they are any good or is this just repeating common wisdom? Some arguments in favour of longer lines would be: - monospaced fonts are relatively wide so the line is not long in terms of the number of characters - there can be a lot of non-length on the left hand side due to indentation (especially in Linux where tabs are wide) - programmers are relatively literate and so might perform better than average at finding the start of the line - editor features like line highlighting can help to find the line - source code has a very ragged edge and so it is easier to find the start of the line than in dense prose. - magazines or their readers prefer narrow columns for stylistic reasons. E.g. newspapers sometimes have very narrow columns that lead to intraword spacing that makes things hard to read
tpoacher 5y ago
It depends. This is not an unbroken rule. E.g. if you have 4 long lines all following the same pattern with minor modifications, the best way to both scan quickly and avoid bugs is to write them on their own line fully and align the common parts vertically. Splitting each line into smaller parts for the sake of "vertical scanning" actually achieves exactly the opposite in this case.
lenkite 5y ago
Book lines are not indented at different nested levels while code is. So, unless your line limit is 72char+indentation, it makes little sense to follow this deeply cumbersome policy which will result in developers making single letters for all variables and 2/3 letter function/method names.

coldtea 5y ago

Even PEP8 says "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 length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters."

indymike 5y ago
> it is okay to increase the line length limit up to 99 characters PEP8 is strongly biased towards making code readable, and has helped a generation of programmers start thinking about readability when coding. The line length limit, though, is one of the few parts of PEP8 that introduced defects as a practice. Holding to 80 characters causes: * string concatenation bugs from breaking up long strings * errors in expressions broken up into multiple expressions just to fit * bias to use shorter variable names My favorite part of PEP8 was the warning about "foolish consistency".
- unixhero 5y ago
  Are we supposed to be reading the PEPs?
  - novok 5y ago
    If you care about the reasoning behind whatever feature they are implementing.
GoblinSlayer 5y ago
Comments suffer even more from line length limit. I saw it many times when a comment is changed and then all following lines get rewrapped.

Diggsey 5y ago

- Code is not prose. It's not read like a book so it's not clear that an "ideal measure for continuous text" is at all relevant. - Most lines are short even if the limit is more than 80 characters, so you're unlikely to accidentally shift up or down after reading a long line. - Even if there turns out to be some benefit for reading code based on Saccades, that means nothing unless you can make some quantitative comparison with the other advantages and disadvantages of a longer line length.

throwawayboise 5y ago
For me it's not just the length of the line but the level of indentation. I think wide indents are good for readability, so if you're using standard tabs and also sticking to 80 columns as a hard limit then you have only 64 characters to work with at two levels of indentation. Excessive indentation is a clue that you may want to refactor, but two levels is pretty common. 80 charcters starting at the point of indentation is more reasonable. At two levels of indenting, you might get out to 96 characters, which still fits comfortably in most GUI terminal windows.
- AlphaSite 5y ago
  W is the bare minimum, it’s a function and a conditional or loop, 3 or 4 is pretty common.
xxpor 5y ago
The biggest problem with short lines isn't even the line length, it's that it encourages stupid variable names in order to keep things on one line. Silly abbreviations that no one new to the code can figure out are the bane of my existence.
lgrapenthin 5y ago
Why does code have to be "read like a book" to be considered "continuous text"? Of course code is continuous text.
- tasogare 5y ago

jagger27 5y ago

> I take the even more draconian approach of wrapping to 72 columns when writing comments, after the fashion of PEP 8.[3] Which also happens to be how Linus wrapped the lines of this particular email.

SonOfLilit 5y ago
Plaintext email is wrapped to 72, that's in the RFC - Linus didn't have much choice there.
- rhn_mk1 5y ago
  Sure did: > Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 https://www.arp242.net/email-wrapping.html https://www.arp242.net/email-wrapping.html

coldtea 5y ago

That's for books. When reading code, I'd rather see a single statement on one line, rather that break it at 2 lines because it passed some ancient 80 char limit...

d0mine 5y ago
"ancient" doesn't mean wrong. Round wheels are ancient, it doesn't mean we should switch to the square wheels.
- cortesoft 5y ago
  It doesn't mean right either, and the person you are responding to gave specific reasons why they prefer longer.
  - kortilla 5y ago
    So it’s almost as if the “ancient” qualifier was useless.
    - cortesoft 5y ago
      Well it was clearly meant to imply that the reason we are using it is merely tradition, and that there was a reason a long time ago that no longer applies.
    - coldtea 5y ago
      It was intended to mean "relavent in old times".
- coldtea 5y ago
  >Round wheels are ancient, it doesn't mean we should switch to the square wheels. No, but it means we better use rubber wheels, not stone ones...
- hsbauauvhabzb 5y ago
  We also shouldn’t burn people deemed witches at the stake. Being ancient doesn’t make it right, either.

weego 5y ago

1) has tenuous relevance at best 2) The 80 or 66 char or whatever is literally a non-science driven designer rule of thumb that's actually the opposite conclusion from results of actual research into the issue (granted it's not exactly a deeply studied niche but there is research).

phil294 5y ago

When "visually scanning" code, in 90% of the cases, only the first 10 characters matter anyway, so I fail to see your point. How often do you really need to grasp, say, all function arguments at once?

michaelcampbell 5y ago

These opinions about readability "flow" using numbered footnotes strikes me as the height of irony, but that's me.

lobocinza 5y ago

Arbitrary line breaking is ugly and a unnecessary source of errors. I avoid writing lines longer than 80 chars but in some cases it feels better and more ergonomic/readable to exceed it.

dan-robertson 5y ago

I think I heard somewhere that the studies about line length don’t actually give very strong evidence in favour of short lines. On the other hand, I don’t have a source for that. Do you know if they are any good or is this just repeating common wisdom? Some arguments in favour of longer lines would be: - monospaced fonts are relatively wide so the line is not long in terms of the number of characters - there can be a lot of non-length on the left hand side due to indentation (especially in Linux where tabs are wide) - programmers are relatively literate and so might perform better than average at finding the start of the line - editor features like line highlighting can help to find the line - source code has a very ragged edge and so it is easier to find the start of the line than in dense prose. - magazines or their readers prefer narrow columns for stylistic reasons. E.g. newspapers sometimes have very narrow columns that lead to intraword spacing that makes things hard to read

tpoacher 5y ago

It depends. This is not an unbroken rule. E.g. if you have 4 long lines all following the same pattern with minor modifications, the best way to both scan quickly and avoid bugs is to write them on their own line fully and align the common parts vertically. Splitting each line into smaller parts for the sake of "vertical scanning" actually achieves exactly the opposite in this case.

lenkite 5y ago

Book lines are not indented at different nested levels while code is. So, unless your line limit is 72char+indentation, it makes little sense to follow this deeply cumbersome policy which will result in developers making single letters for all variables and 2/3 letter function/method names.