9 ms·

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take

by js2 6y ago

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl). Those that liked the 35 cpl indicated that the short line length facilitated "faster" reading and was easier because it required less eye movement. Those that liked the 95 cpl stated that they liked having more information on a page at one time. Although some participants reported that they felt like they were reading faster at 35 cpl, this condition actually resulted in the slowest reading speed. The Effects of Line Length on Reading Online News[1] 1. http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... For slabs of body copy, I like about 70 characters per line, but anything in the 50-80 range seems good. I also think justified text is harder to read, due to the lack of unique shapes to track on the right side of text — it's far easier to lose your place. https://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed https://graphicdesign.stackexchange.com/questions/13724/reco... I still often code on a 13" Macbook where I can open a pair of side-by-side windows in my editor with the dock on the side and get about 95 characters into each window. I typically code in Python and use a 4 space tab and a font legible to my 48 year-old eyes w/o reading glasses. On my external monitor, I take advantage of the extra width to open additional windows. So I dunno, still prefer 80-88 characters for coding, 100 max. The grep thing seems like a red-herring. Use grep's -A, -B, and -C options to get more context.

vlovich123 6y ago
Is there any research to suggest that reading legibility of code is the same as for regular text? Unlike regular text code often has special characters & indentation to break it up, so intuitively I would assume it could support longer line lengths.
- chipotle_coyote 6y ago
  I was wondering the same thing, yes. I'm often an annoying stickler about keeping line length for text on the web set to what a couple centuries of book design have taught us makes long-form prose more readable, but code is not prose. I try to keep multi-line comments wrapped to around 78 characters, but I'm not really too worried about code. (This invites a rant about people, usually people who use Emacs, who put hard line breaks in text paragraphs, but I'll save it for another time.)
- stock_toaster 6y ago
  Yeah, we cant forget whitespace (indenting, space alignment, etc). In a 100 char wide code line, how many actual non-whitespace chars would there be on average?
nicoburns 6y ago
Shirt lines have the problem that they make it much more difficult to scan the whole document for someyhing because they increase vertical distance. You can fit less on the screen at once. I actually prefer long lines even if I have a small screen and need to horizonally scroll. Often the content at the end of the line isn't even that important.
TheDong 6y ago
Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is line-oriented (same for sed, etc). Sure, it's possible to make the output have context, but to actually do a multi-line grep correctly is much more complex. I think that's the sort of grep usage linus was referring to. > So I dunno, still prefer 80-88 characters for coding, 100 max. I also prefer most lines to be under 80 characters, but for the sake of keeping a function call on one line, or keeping important things together, I'm fine with exceptions. Some code splits onto multiple lines naturally (like moving a function call in a function's arguments into its own temporary variable). Other times, it becomes less readable as several shorter lines. Thus I don't think a hard rule of 80 is good, simply a general philosophy that readable code is good and that's more important than line length.
- joshuamorton 6y ago
  Well the real answer is that we shouldn't treat code as "line oriented". It's a tree. Use a tool meant for tree processing, like clang-format or the various similar tools for other languages. These let you query the AST or CST of the language, which is very useful. Often you combine this with a line oriented but overly false-positive prone query, like a file-level grep for `foo`, since the AST parsing is slower. Then you reprocess with AST-based tools. There's some fairly ergonomic tooling for this kind of transformation, although often you need a tool per language, which is annoying.
  - saagarjha 6y ago
    Unfortunately, this now means that your code searching tool must have knowledge of the language you are running it on. Generally, since you want one tool, that means it needs to either support them all or be designed like LSP…
    - _ZeD_ 6y ago
GuiA 6y ago
Yeah, when you do typesetting you quickly learn that ~10 words per line is a sweet spot for readability.
- lostmyoldone 6y ago
  I wonder what the equivalent of 10 words is for code in <programming language> ? The large number of symbols in many languages that are clearly not words in the usual sense might make the comparison a bit tricky, or wouldn't it ?
KODeKarnage 6y ago
One line, one idea. That's the goal. Your eye doesn't need to move if you can get the information you need from the first 30 characters. Two lines, one idea. That's a recipe for cognitive disaster. It forces you to read the entirety of the preceding line to understand what is happening on the next one. As a good example, reading logs. You can scan down the log to find what you want. Imagine if the time was placed at the end of the line. It doesn't matter how many characters on a line in that case, the reading the log is a massive cognitive load.
deleted 6y ago
[deleted]
ssivark 6y ago
It really doesn’t matter. We must strive to separate content and presentation, so people could choose whatever presentation they like (and have the editor do the wrapping as desired), for whatever whimsical reason that is nobody else’s business. It’s crazy to keep having this discussion and debating what the “research” indicates. C’mon, haven’t we made any progress in forty years!? Everybody can have their own damn bikeshed, and paint it a different color every day. Personally, I like to see more things happening in one screenful, so artificially imposed line breaks are really really annoying and break momentum when reading/scanning code.
- justaguy88 6y ago
  Ah so you're "tabs" haha
  - wolrah 6y ago
    100% the reason I'm a tab guy. If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here...). To me that is a significant objective advantage of tabs, where the only advantage spaces seem to offer is that you can align text on multiple levels of indentation.
    - PunksATawnyFill 6y ago
      Yep. I have yet to hear a coherent argument against tabs. It’s such a tiresome squabble.
      - sam_lowry_ 6y ago
        Douglas Crockford made an interesting argument in favour of spaces: https://www.youtube.com/watch?v=En8Ubs2k1O8 https://www.youtube.com/watch?v=En8Ubs2k1O8
ogre_codes 6y ago
> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width. Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. But having the option to use longer lines when it makes the code more readable is also valuable. Putting a fairly short, arbitrary limits on line length just makes other parts of coding less pleasant, variable names in particular suffer quickly when you can't make comparisons on a single line. Where I work, we wrap lines at 120 characters but the overwhelming majority of the code is less than 80 characters wide. Longer lines are reserved for if statements with multiple conditions or ternary assignments.
- l0b0 6y ago
  Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.
  - taeric 6y ago
    It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?
    - fauigerzigerk 6y ago
      It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right. Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next. Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text. So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.
ryandrake 6y ago
The problem with this idea is you then get these web site designers who take it as dogma and try to force a particular width, without regard for the browser window size. This results in sometimes 1/2 or more of the horizontal area on the page wasted by this giant white space border. If you must have a margin, at least make it a reasonable percentage of the browser window width. Or better yet, don’t force my browser to render a margin.
- hinkley 6y ago
  Somewhere I have a picture of daringfireball taking up around a quarter of the monitor width and just blank space around it.
  - zapzupnz 6y ago
    The stylistic choice there may be informed by macOS' window manager defaulting the window size to "just big enough to fit the content". It's only really since full-screen windows came to play that the issue with Daring Fireball really become obvious; prior to that, macOS users rarely made their windows fill the screen in the same way that Windows users are prone to do.
    - charrondev 6y ago
      > that Windows users are prone to do. Or how iOS users tend to do.
      - zapzupnz 6y ago
        Indeed. I was thinking about iPads, but I didn't mention it because the design predates iOS — but yes, it's absolutely true. And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.
deleted 6y ago
[deleted]
manquer 6y ago
Unlike text in print, code is not a paragraph, in typical code every line is not going to be that long. I am not sure the same rules can apply. I find that breaking a line at 80/120 makes the piece of code I am trying to understand less readable, while the line itself may have become more readable.
978e4721a 6y ago
Yeah, bad tools shouldn't justify bad decisions. Build better tools god damn it.
yellowapple 6y ago
> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. This is indeed why a large number of books and articles and papers opt for multiple-column formats. Frequent line breaks also help better break up distinct pieces that warrant independent examination, much like how such breaks in poetry help isolate distinct thoughts. There are certainly cases where such a "thought" does indeed exceed that 80-line limit, but I've found that they are rare (though this obviously depends on the language; for example, in my day job my T-SQL code frequently exceeds that arbitrary limit, simply because it often takes more characters to express a "thought"). All that being said, I wouldn't impose this on an existing project. If Linux's standard is for 100-character lines, then that is the standard to which I'll adhere. For my own code, however, 80 characters is (language limitations notwithstanding) more than sufficient.
cdaven 6y ago
> Reading rates were found to be fastest at 95 cpl. They only tested 35, 55, 75, and 95 characters per line (cpl)! Which means that if they had tested 120 cpl, THAT could have been "fastest".

by js2 6y ago

vlovich123 6y ago

Is there any research to suggest that reading legibility of code is the same as for regular text? Unlike regular text code often has special characters & indentation to break it up, so intuitively I would assume it could support longer line lengths.

chipotle_coyote 6y ago
I was wondering the same thing, yes. I'm often an annoying stickler about keeping line length for text on the web set to what a couple centuries of book design have taught us makes long-form prose more readable, but code is not prose. I try to keep multi-line comments wrapped to around 78 characters, but I'm not really too worried about code. (This invites a rant about people, usually people who use Emacs, who put hard line breaks in text paragraphs, but I'll save it for another time.)
stock_toaster 6y ago
Yeah, we cant forget whitespace (indenting, space alignment, etc). In a 100 char wide code line, how many actual non-whitespace chars would there be on average?

nicoburns 6y ago

Shirt lines have the problem that they make it much more difficult to scan the whole document for someyhing because they increase vertical distance. You can fit less on the screen at once. I actually prefer long lines even if I have a small screen and need to horizonally scroll. Often the content at the end of the line isn't even that important.

TheDong 6y ago

Let's say I want to find every function call too `foo` that passes `true` as the last argument. I might do something like `grep "foo\(.*true\);"` That would work well enough if the codebase was mostly uniform and all calls to foo were on a single line. However, if we have callsites like "foo(x->y(get_arg(z)), something, \ntrue);" where 'true' is split onto a newline, that naive grep misses it. As linus says, grep is line-oriented (same for sed, etc). Sure, it's possible to make the output have context, but to actually do a multi-line grep correctly is much more complex. I think that's the sort of grep usage linus was referring to. > So I dunno, still prefer 80-88 characters for coding, 100 max. I also prefer most lines to be under 80 characters, but for the sake of keeping a function call on one line, or keeping important things together, I'm fine with exceptions. Some code splits onto multiple lines naturally (like moving a function call in a function's arguments into its own temporary variable). Other times, it becomes less readable as several shorter lines. Thus I don't think a hard rule of 80 is good, simply a general philosophy that readable code is good and that's more important than line length.

joshuamorton 6y ago
Well the real answer is that we shouldn't treat code as "line oriented". It's a tree. Use a tool meant for tree processing, like clang-format or the various similar tools for other languages. These let you query the AST or CST of the language, which is very useful. Often you combine this with a line oriented but overly false-positive prone query, like a file-level grep for `foo`, since the AST parsing is slower. Then you reprocess with AST-based tools. There's some fairly ergonomic tooling for this kind of transformation, although often you need a tool per language, which is annoying.
- saagarjha 6y ago
  Unfortunately, this now means that your code searching tool must have knowledge of the language you are running it on. Generally, since you want one tool, that means it needs to either support them all or be designed like LSP…
  - _ZeD_ 6y ago

GuiA 6y ago

Yeah, when you do typesetting you quickly learn that ~10 words per line is a sweet spot for readability.

lostmyoldone 6y ago
I wonder what the equivalent of 10 words is for code in <programming language> ? The large number of symbols in many languages that are clearly not words in the usual sense might make the comparison a bit tricky, or wouldn't it ?

KODeKarnage 6y ago

One line, one idea. That's the goal. Your eye doesn't need to move if you can get the information you need from the first 30 characters. Two lines, one idea. That's a recipe for cognitive disaster. It forces you to read the entirety of the preceding line to understand what is happening on the next one. As a good example, reading logs. You can scan down the log to find what you want. Imagine if the time was placed at the end of the line. It doesn't matter how many characters on a line in that case, the reading the log is a massive cognitive load.

deleted 6y ago

[deleted]

ssivark 6y ago

It really doesn’t matter. We must strive to separate content and presentation, so people could choose whatever presentation they like (and have the editor do the wrapping as desired), for whatever whimsical reason that is nobody else’s business. It’s crazy to keep having this discussion and debating what the “research” indicates. C’mon, haven’t we made any progress in forty years!? Everybody can have their own damn bikeshed, and paint it a different color every day. Personally, I like to see more things happening in one screenful, so artificially imposed line breaks are really really annoying and break momentum when reading/scanning code.

justaguy88 6y ago
Ah so you're "tabs" haha
- wolrah 6y ago
  100% the reason I'm a tab guy. If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here...). To me that is a significant objective advantage of tabs, where the only advantage spaces seem to offer is that you can align text on multiple levels of indentation.
  - PunksATawnyFill 6y ago
    Yep. I have yet to hear a coherent argument against tabs. It’s such a tiresome squabble.
    - sam_lowry_ 6y ago
      Douglas Crockford made an interesting argument in favour of spaces: https://www.youtube.com/watch?v=En8Ubs2k1O8 https://www.youtube.com/watch?v=En8Ubs2k1O8

ogre_codes 6y ago

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width. Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed. But having the option to use longer lines when it makes the code more readable is also valuable. Putting a fairly short, arbitrary limits on line length just makes other parts of coding less pleasant, variable names in particular suffer quickly when you can't make comparisons on a single line. Where I work, we wrap lines at 120 characters but the overwhelming majority of the code is less than 80 characters wide. Longer lines are reserved for if statements with multiple conditions or ternary assignments.

l0b0 6y ago
Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.
- taeric 6y ago
  It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?
  - fauigerzigerk 6y ago
    It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right. Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next. Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text. So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.

ryandrake 6y ago

The problem with this idea is you then get these web site designers who take it as dogma and try to force a particular width, without regard for the browser window size. This results in sometimes 1/2 or more of the horizontal area on the page wasted by this giant white space border. If you must have a margin, at least make it a reasonable percentage of the browser window width. Or better yet, don’t force my browser to render a margin.

hinkley 6y ago
Somewhere I have a picture of daringfireball taking up around a quarter of the monitor width and just blank space around it.
- zapzupnz 6y ago
  The stylistic choice there may be informed by macOS' window manager defaulting the window size to "just big enough to fit the content". It's only really since full-screen windows came to play that the issue with Daring Fireball really become obvious; prior to that, macOS users rarely made their windows fill the screen in the same way that Windows users are prone to do.
  - charrondev 6y ago
    > that Windows users are prone to do. Or how iOS users tend to do.
    - zapzupnz 6y ago
      Indeed. I was thinking about iPads, but I didn't mention it because the design predates iOS — but yes, it's absolutely true. And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.

deleted 6y ago

[deleted]

manquer 6y ago

Unlike text in print, code is not a paragraph, in typical code every line is not going to be that long. I am not sure the same rules can apply. I find that breaking a line at 80/120 makes the piece of code I am trying to understand less readable, while the line itself may have become more readable.

978e4721a 6y ago

Yeah, bad tools shouldn't justify bad decisions. Build better tools god damn it.

yellowapple 6y ago

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. This is indeed why a large number of books and articles and papers opt for multiple-column formats. Frequent line breaks also help better break up distinct pieces that warrant independent examination, much like how such breaks in poetry help isolate distinct thoughts. There are certainly cases where such a "thought" does indeed exceed that 80-line limit, but I've found that they are rare (though this obviously depends on the language; for example, in my day job my T-SQL code frequently exceeds that arbitrary limit, simply because it often takes more characters to express a "thought"). All that being said, I wouldn't impose this on an existing project. If Linux's standard is for 100-character lines, then that is the standard to which I'll adhere. For my own code, however, 80 characters is (language limitations notwithstanding) more than sufficient.

cdaven 6y ago

> Reading rates were found to be fastest at 95 cpl. They only tested 35, 55, 75, and 95 characters per line (cpl)! Which means that if they had tested 120 cpl, THAT could have been "fastest".