
Excessive line breaks are bad - trias
http://lkml.iu.edu/hypermail/linux/kernel/2005.3/08168.html
======
merricksb
Big discussion about this post a few days ago:

[https://news.ycombinator.com/item?id=23356607](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...](https://www.kernel.org/doc/html/v4.10/process/coding-style.html)

~~~
teambayleaf
The discussion was originating from this patch:

[https://lkml.org/lkml/2020/5/28/78](https://lkml.org/lkml/2020/5/28/78)

[https://lkml.org/lkml/2020/5/28/1237](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.

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

