Excessive line breaks are bad

[merricksb]

Big discussion about this post a few days ago:

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

[pbw]

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

[teambayleaf]

The discussion was originating from this patch:

https://lkml.org/lkml/2020/5/28/78

https://lkml.org/lkml/2020/5/28/1237

Although you're right that his comment made the coding standard ambiguous, I found myself agreeing with Linus in this particular case. What we need to do often in a large C project is to grep some function prototype against the source tree, and it sucks if it's wrapped like this.

[AnssiH]

I believe they are talking about existing code - i.e. Linus does not want patches to re-wrap existing long lines just to get them under 80.

For new code 80 columns is still the recommendation, unless this discussion causes that to be changed.

[iforgotpassword]

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.

[m463]

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.

[saidajigumi]

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.

[jkhdigital]

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

[errantspark]

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

[greatgib]

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

[gcoda]

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'

[sh-run]

I have no problem with 80 lines side by side with vscode taking up half of my 3440x1440 display (so 200px less wide than a single 1920 × 1440 display). Even with the extra space taken up by the github UI, I can't imagine 40 additional chars is a big deal.

Even at 80 I occasionally sacrifice readability for line breaks to keep my company's linter from throwing a fit. 60 does not sound like a good idea to me.

[dkdk8283]

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.

[C1sc0cat]

Vt100's could do 132 back in the late 70's