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]
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.
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.
> 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.
> 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.
This kind of thing is really obtuse and it drives me insane that so many people subscribe to ideas like these.
This kind of thinking is what leads to linters with completely arbitrary rules telling me how I should solve my own problem.
Me: "Hey linter, I'm going to shadow a variable name here, because that's the right thing to do in this situation, so shut up about it."
Linter, and 5 billion HN commenters: "you're shadowing a variable. Compile warning."
Me: "it's a language feature, and it's ok to use."
Linter: "you're shadowing a variable. Compile warning."
Etc.
Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day.
I PROMISE that a human brain is better at discovering general code quality problems than the best linter with the best rules, and that will be true until a time when every reasonable computer is a general purpose AI.
Yes, tell me when I have a memory leak. Use static analysis to tell me about weird issues I have difficulty seeing. I know best about line width and how to solve things in my own application better than any linter could ever hope to, because linters do not have anything approximating the intelligence of gnat, nevermind a human being.
> Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day.
Linters' line length rules solve a problem of useless bikeshedding and introduce consistence to the code. This already helps everyone involved in reading and writing the code.
If people were interested in stopping the bikeshedding, they would create an editor that let everyone view the code however they please, and check in with a consistent format that doesn't matter. Extensions for source control tools and debuggers would quickly point to the token that caused an issue, for example, rather than the line number.
Instead everyone just creates rules that they like, then force those rules on everyone else as a power move, then use "this is for consistency and anti-bikeshedding" as an excuse to keep their own preferences enforced on others.
And before anyone argues, I've seen it happen multiple times. I swear people become team leads solely to force their preferences on others. They certainly are fond of power trips, in my experience.
> Arbitrary rules like line width help exactly 0 people per day
I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored.
I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.
> Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day.
I have no idea why you think I am arguing for stuffing arbitrary line lengths in code. I was arguing for the exact opposite, that line length limits are rarely beneficial.
I am skeptical but curious. I honestly can't think of one. The closest one I can think is maybe you have some kind of macro that uses a temp variable? like a swap macro? But i think you can still have a unique variable name for that particular line if you want?
But if these cases are exceptional then you can use pragma to suppress those warnings for that particular block of code. If they are not exceptional perhaps you shouldn't have enable the warning/linter check for that warning.
But honestly I can't think a good reason for shadowing variables and would appreciate an example
> "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."
I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.
Just skimming our codebase, 20+ character variable names are fairly common. Even with verbose variable names, the majority of our lines of code are less than 80 characters. Probably 1 our of every 15-20 lines of code stretches longer and we greatly appreciate that we can go longer, but the majority are shorter.
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.
Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading...
Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition.
Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.
>But we don't have a ton of empirical evidence on our side
Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all.
The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left edge). That's not usually the case for indented code.
If reading long lines takes more effort because your eyes have to travel further to find the next line, then the amount of indentation the next line has matters are great deal.
My point was that there is no writing that extends to long lines. If anything, the fact that no other writing form has made such extensive use of indentation is enough to give me pause and think if that is making any sense. (I do note the amusing lines in the Linux style guide on the use of heavy indentation.)
And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.
> If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems
In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns.
I agree, math is a perfect example where code is more clear to have a single long statement on one line. I am a bit skeptical that you have a big codebase with math on more than a quarter of the lines of code though. Most likely there are a lot of shorter lines between your formulas which is exactly my point here.
When long lines improve readability/ clarity you should have the ability to use them.
Tell that to 'functional programming' people, or the lambda-crazy people who put entire functions in argument lists to the point you can't parse a statement to save your soul. I've had to print and highlight code to figure out where it began and ended.
> ...who put entire functions in argument lists to the point you can't parse a statement to save your soul.
As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.
> As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.
Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.
> Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width.
No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.)
Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.
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.
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.)
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.
This. The problem itself has nothing to do with the number of characters you have on a line - the problem is that the vast majority of programming tools today conflate content and presentation.
The job of making sure the line length is reasonable is not up to the writer of the code - it is up to the tools that are used to read it. Lines should be as long as necessary, and then intelligently (i.e. syntactically-aware) soft line-wrapped by the editor when opened.
> the problem is that the vast majority of programming tools today conflate content and presentation.
This is not a problem, but a beautiful and crucial property of text files. I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question
> I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question
Adjustable tab display width and automatic line wrapping are features any good text editor offers that do not interfere with the use of any other text manipulation tools on that file.
Now, if you're forced to work in an environment where someone wrongheadedly decided to adapt to users who have bad or badly configured editors and standardized on space indentation that sucks, but that's the fault of whoever made that bad decision.
I try to keep my Clojure code under 80 characters (so that I can have three editors comfortably side by side at my preferred font size) and keeping lines short is more than just where to wrap or other visual-only things. Usually when I have a long line, it makes me reconsider the structure of the code and I refactor it into something else. Most of the time, the new structure not only has shorter lines, but is simpler too, so its a double win. This isn’t always a task that the tools could do for mem, though, as it sometimes rewuires rethinking what I’m trying to accomplish.
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.
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.
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.
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.
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.
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.
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.
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…
I do this sort of grepping regularly, and would love a more code-oriented tool. Ignore whitespace, integrate syntax notions...
For example for a function foo, it's needlessly hard to grep for its declaration, imports and calls independently. Looking for one will probably surface the others.
I have a fairly simple solution for the scenario you’ve presented. grep, and return some context (maybe +5) and then grep on that again with the argument you’re looking for (give a negative context this time so you get the entire function call)
That being said, as unlikely that scenario is, having it all in 1 line does not work either. The problem is that its very likely/possible that the true argument will be passed in in the form of a variable. So you’re back to needing something that is more code aware anyways.
> where 'true' is split onto a newline, that naive grep misses it.
This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_, if someone is splitting code by inserting unnatural breaks then they are trying too hard, OR there could be various other legitimate reasons like very long function names and naturally verbose PL syntax that make even longer line widths unreasonable. Regardless of width constraints many people will split the arguments of extremely long function signatures onto multiple lines out of preference anyway, then grep will still get stuck without more caring regex.
These arguments always emerge out of someone misinterpreting guides as absolutes. No one is arguing we need to stick to 80 column terminals otherwise everyone would autowrap their commits and we'd have horribly unreadable breaks everywhere. 80 is historical, but trying to keep code width short does improve legibility, 80 just turned out to be a pretty good human standard as well.
> This misses the point, same as Linus (which i honestly find surprising)... 80 width lines is a target to try to achieve _naturally_,
The post is about changing code style formatting rules for code that goes into the Linux kernel. Not guidelines, rules. The tools in question, I presume to be a linter or formatter, complained noisily about line length prior to the adoption of this change.
It's not about someone misinterpreting guides as absolutes. It's very much about absolutes, in this case, that serve as guides.
> 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.
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.
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/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/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.