The Linux Kernel Deprecates The 80 Character Line Coding Style

[goTouch]

The script should count how many long lines exist in every 20 lines. It is totally fine to see one long line occasionally, but not several long lines on every page.
Even on big screen, people still open multiple windows and tile them. And people now use laptop more than before.
Long lines still hurt. I feel 120 actually is too long. Long lines of conditions etc, should be broken up to multiple lines. Function prototypes with many parameters should
use multiple lines in sensible way. Variable names are usually not long and not a concern.

[goTouch]

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.

Who is coding kernel in an IDE? I bet most people use multiple windows much more often.

[ssokolow]

Gonna have to start splitting the screen horizontally instead of vertically.

I'd share the same complaint, but my preferred Vim font is already a hair too large to fit two 80-col columns on my 1280x1024 secondary monitors and :vsplit works fine with Rust's 100-column default on my centeral 1920x1080 monitor.

[doragasu]

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.

⬆⬆⬆⬆ this ⬆⬆⬆⬆

[dc_coder_84]

Why is there a limit after all? If there are really some ugly long lines of code the reviewers can easily reject the patch and ask for code improvements.

[M@GOid]

This is something that we should get outraged about? It sure feels like something to get outraged, like some sacred cow got waked or something.



On a more serious note, if I was Linus, I'd put some hard limit there, because if you give some space to some people, they will consider it a free real state and the madness begin.

[shmerl]

Yeah, long overdue. 120 or even more are quite normal standards. We are not in the '80s anymore, good displays are easily available and very much preferable for easier reading.

[F.Ultra]

Why is there a limit after all? If there are really some ugly long lines of code the reviewers can easily reject the patch and ask for code improvements.

With a rule it's much easier to reject said code without having a lengthy discussion on if the code was rejected for the right reasons and so on. Also it helps the automated script reject those patches way earlier in the process.

[macemoneta]

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.

Actually it dates back to IBM mainframe punch cards, which had a maximum of 80 characters. When we switched to terminals (hardware, not software), they were designed to display the 80 columns that a card would contain per line. That software coding style dates back to 1928.

[intelfx]

my 1280x1024 secondary monitors

my centeral 1920x1080 monitor

Get yourself better monitors.