The Linux Kernel Deprecates The 80 Character Line Coding Style

[Teggs]

This sounds like what I used to run into with grammar editors. I'd write some perfectly acceptable 50-word sentence, and the editor would flag it as incorrect. I'd look over the sentence, and eventually come to the conclusion that it wasn't actually parsing the structure, someone just entered a hard word limit. 'Anything over 30 words is automatically wrong', or something. My grammar wasn't wrong. The editor was wrong, and its error message was a waste of my time.

Never used a grammar editor since. Or a spell-check (on purpose) since those haven't become any more intelligent over time either.

It sounds to me that Linus is trying to make the style guide more fit for purpose, and more power to him.

[birdie]

Totally missing the point?
80 chars was not much of a thing because of resolution or terminal width even 25 years ago.
It's because 80 chars actually served a purpose in forcing people to write readable code instead of nested hell and variables in novel form.
It still does to this day. We are still talking about C and the Linux kernel.

The issue I have with increasing this limit is when does 100 chars become the "occasional line" instead of the norm?
To my eyes, kernel code written to exceed more than 80 chars is usually badly structured, badly nested or generally suffer in the readability department.

50 years ago when that was the first standard the code was a LOT simpler than now. You're missing more than a point and your knee-jerk reaction proves that.

There was no Java back then, not even classes and inheritance. Computer HW was a lot more primitive. No MMX, SSE, AVX, OpenGL, DirectX, Vulkan, GUI, etc. etc. etc. Computers couldn't play audio or video. Oh, yeah, there was no GUI back then aside from Norton Commander which isn't really an example of a GUI application. It was pseudo graphics.

[Larry$ilverstein]

Get yourself better monitors.

1080 is fine for a small-ish screen on a desk. The consoomers who "can't live without" an 8K screen, 10 inches away from their face are just fake connoisseurs.

[Raka555]

This sounds like what I used to run into with grammar editors. I'd write some perfectly acceptable 50-word sentence, and the editor would flag it as incorrect. I'd look over the sentence, and eventually come to the conclusion that it wasn't actually parsing the structure, someone just entered a hard word limit. 'Anything over 30 words is automatically wrong', or something. My grammar wasn't wrong. The editor was wrong, and it's error message was a waste of my time.

Never used a grammar editor since. Or a spell-check (on purpose) since those haven't become any more intelligent over time either.

It sounds to me that Linus is trying to make the style guide more fit for purpose, and more power to him.

It is actually people that are getting dummer over time.
The average sentence length was over 60 in the 1500's and kept declining over time.

"Modern" humans get a cognitive overload when you go past 14 words in a sentence today:
(It is probably even shorter than that today)


https://medium.com/@theacropolitan/s...s-2e40f80f589f


No wonder the poor programmers can't cope with added cognitive load of manual memory management on top of that today...

[torsionbar28]

The average sentence length was over 60 in the 1500's and kept declining over time.

"Modern" humans get a cognitive overload when you go past 14 words in a sentence today:

This sounds like a solution to me. Instead of 80 or 100 characters per line, it should be 14 words per line. Bonus points for using ridiculously long German words like Zusammengehörigkeitsgefühl or Geschwindigkeitsbegrenzung or Hochgeschwindigkeitsbahnsystem.

[Raka555]

50 years ago when that was the first standard the code was a LOT simpler than now. You're missing more than a point and your knee-jerk reaction proves that.

There was no Java back then, not even classes and inheritance...

I beg to differ. The constructs was not called classes, inheritance OO etc, but it were there. It was much more advanced than you give it credit for.
There is actually very little that is new in "modern" software.

Please watch the following presentation. I was amazed at what was there before.

https://www.youtube.com/watch?v=eEBO...&index=30&t=0s

[tchiwam]

Punched paper on my DEC writter II and III was 132 char / lines.

[krOoze]

Myeees. Everything goes according to my evil plan. Now to switch indentation into tabs.

[microcode]

It's mostly line wrapping length relative to the (1080p - width-of-IDE-sidebar)/<font size in px>. It's literally most common width of convenience based on actual hardware/software/font size people are using.

Basically zero kernel programmers use an IDE like that, FWIW.

It's more to do with reviewing code and patches in a terminal emulator.

[JustRob]

I've been in the '120 club' for decades, but only when you can get away without having to read the end of lines frequently; since narrow terminals fit more per screen or permit other windows to be wider. Always look for a prime spot to split before you near 80, while allowing the continuation to be nearly as long as the preceding line; otherwise just make the line longer.

It's partly about fitting more on the screen, but that includes other windows too, readability is key and getting enough information exposed in 'one block' (area) of the screen to make that portion of the code's function obvious; to avoid end of line comments and hopefully allow header and interstitial comment blocks to document the code adequately.

Much as panoramic photos are nice in some ways they don't immediately convey the whole picture, which is their purpose, neither is portrait mode a good style for coding as the purpose flows off the screen rather than conveying the whole picture in the smallest self-contained square. If it's really getting unwieldy there are macros and defs (along with a clear comment block) that should be considered when the purpose of a block of code becomes too wide or long.