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.

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.

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.

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.

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.

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.

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

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.

Really, is there any writing that doesn't seem to apply?

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.

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.

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.

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.

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.

See, e.g. [1].

[1] https://docs.fast.ai/dev/style.html

When long lines improve readability/ clarity you should have the ability to use them.

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.

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.

In a 100 char wide code line, how many actual non-whitespace chars would there be on average?

(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.

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.

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

If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.

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.

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.

It’s such a tiresome squabble.

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.

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.

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.

Or how iOS users tend to do.

And he hasn't optimised the design for iPhone-sized devices much but I think that's deliberate.

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.

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.

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.

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.

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.

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.

Then it is about absolutes, the rule is absolute, but 80 width is a guide... being used as a rule.

I'm surprised the first to challenge the rule is about grepability and not how detrimental it is to legibility to use this as a hard rule.

  perl -pe 's/\\\n//g'

  foo(1, bar, false)
  print("Hello, world")
  flag = true

  foo(1, \
      bar, \
      false)
  print("Hello, world")
  flag = \
      true

  foo(1, bar, false)
  print("Hello, world")
  flag = true

  foo(1, bar, false)

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 ?

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.

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".