Big discussion about this post a few days ago:

https://news.ycombinator.com/item?id=23356607

I'm confused. This page [1] claims to be the "Linux kernel coding style" and it says "The limit on the length of lines is 80 columns and this is a strongly preferred limit". So he's reversing that without actually updating the guide? And without setting a new limit? He implies maybe "100" is a good limit but maybe "142" is even better? Weird.

I know he's primarily talking about terminal output not code, but he implies it's for code too "and our source code is fundamentally wider as a result". Seems like a very sloppy transition of a huge project to a new vague standard? I'm not impressed the clarity here.

[1] -https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

Fully agree. Lines should be as long as they need to be, and break where it makes sense, not because some arbitrary limit that stems from a technical decision 40+ years ago is hit.

I liked this comment elsewhere in the thread:

"Tab depth use in the kernel is more or less

  $ git grep -Poh '^\t+(if|do|while|for|switch)\b' | \
  sed -r 's/\w+//g' | \
  awk '{print length($0);}' | \
  sort | uniq -c | sort -rn
  903993 1
  339059 2
  89334 3
  18216 4
  3282 5
  605 6
  148 7
  36 8
  4 9
  1 10

http://lkml.iu.edu/hypermail/linux/kernel/2005.3/06570.html

I like seeing these "back of the napkin" sorts of code snippets revealed... this is the sort of thing that happens frequently but isn't ever shared because of its throwaway/ephemeral nature.

And also, yeah, low tab depth is way more relevant than line length as far as clean code.

This rant feels a bit banal, like it's going up against a straw-man just to be ... a rant. On one hand, I can't think of the last time a developer in an org I've worked with hasn't conspicuously and regularly used text windows wider than 80 columns. On the other, well-written code (and prose!) also exploits limiting line length for clarity and readability. There's clearly a balance, helpful rules of thumb paired with useful times to break those rules.

To be honest, the worst regular example I encounter, in either direction, is Markdown source with no hard line breaks. Markdown fully supports them, and trying to read paragraphs in whatever-hundred character lines is a painful exercise. Such irony, since part of the beauty of Markdown is dual readability in both source and rendered forms.

> But still - it's entirely reasonable to have variable names that are 10-15 characters and it makes the code more legible. Writing things out instead of using abbreviations etc.

This is my main justification for ignoring any particular limit on line length when writing code, especially when I'm using libraries that have really long method names.

I like 80-ish character lines. I'm glad Linus is yelling about this though, dogmatic beliefs are the root of much evil.

I fully agree with his opinion! This deserves to be in the top of HN!

After missing some errors in long lines during code review, i feel like <60 should be the target. side by side diffs are most common view for me in 'github flow'

I’m impressed to see this from Linus. We’ve had terminals wider than 80 chars for awhile - a limit I think needs to be revisited.