The Linux Kernel Deprecates The 80 Character Line Coding Style

[fuzz]

https://stevedower.id.au/blog/most-critical-python-metric

[Raka555]

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

The one thing that is giving computer science of the 60s and 70s a bad reputation, is the mainframe.
I think a lot of people crossed paths with a mainframe at some point and then think that is how all software were done back then.

I crossed paths again today with a mainframe and I can't believe how they do things even in 2020 ...

[Citan]

Seriously, good code can be written and displayed on 80x25 monitors IF the programmer knows how to properly construct their code within the limits of the language and the hardware being used.

When programming labels influence performance I become so depressed at the drastic decline in modern day programming ability compared to decades past. Many of today's programmers would fail to understand why something incredibly critical, like the Apollo Guidance Computer that took Mankind (humans, and possibly some germs too!) to the Moon, was written in Assembly and why it's user interface in the Command Module was so simplistic by today's standards. Do the web research and learn how real programmers worked back in those days; it will amaze (or confuse) you.

Those are just a relent of ideological view construed as a truth.
Yeah, you can write good code with a 80 characters limit. It's just incredibly tedious sometimes, for very little benefit.
Or, please explain how a code that would be written in 100 or even 120 characters would necessarily be bad?
Well, good luck with that, because it's a completely void argument.
Good code will be good even if it's on a 120 characters line. Bad code will be bad even in as short as 50 characters.

But 80 characters is an artificial limit that made sense when displays could simply not bear more conveniently.
100 characters is a limit that will "match" many more use-cases so will simplify daily tasks for most people, whatever language they write in, whatever techology / project / tools they use. And is by the way much closer to the sensible average of written sentences in most "romane" languages.

Are you still programming today? In a real-life entreprise?
Where you never know who will read your code, and how much they pay attention to inline comments?
Where the OOP paradigm is sometimes overrused to wrap up some simple things just to stick in the 80 characters limit?
Where the same OOP means that you may sometimes have half a dozen objects interacting in the same process, each with a different nature and role?
Getting clear cut names for variables and methods (and making those always take type-hinted parameters and returns) makes the code far more lisible
than using "$doc" or "$a" variable names and "$this->process" returns.

Go pick whatever projet in Java or even PHP. You'll see that apart from the most basic methods, anything that is on the "business functional" dimension has an average method name over 15 characters.
And the higher / more custom your get in writing something close to business, the longer will your method name be.
So it's VERY easy to cross the 80 characters limit. Especially when the devs insist on creating variables and method names in their native language (and that is actually the official recommendation of the entity that employs them). But still true even in English.

And the performance impact of having longer names is overall extremely low today. For most use-cases, there is no need to aim for that kind of optimization. Now of course for things such as kernel, this is very important. For "userapps", unless you have some heavy processes, you just need to ensure you're reactive enough for a human user while taking into account how scalability will affect your efficiency obviously, but also the expected limit. No need to twist mind to spare a few extra milliseconds per user request if you know you won't ever have more than a few users at a time and you still get a return within 1, 3, or whatever number of seconds that the user indicated optimal/acceptable.

[Delgarde]

EDIT: oops, just saw your post above mine. Seems we're actually in full agreement. ^^

Indeed. Those tools are immensely useful - but they're dumb, doing nothing more than run a pre-programmed set of rules. Any sizable collaborative project should use them, but only under human supervision.

[Delgarde]

And we have to realize it is also very common people use multiple windows and tile them. So window size is really the key, not monitor size.

Multiple windows, or applications that divide up the screen into pieces, yeah... e.g. the typical IDE with code in the middle, and sidebars for navigation features, tools, etc.

[Citan]

Multiple windows, or applications that divide up the screen into pieces, yeah... e.g. the typical IDE with code in the middle, and sidebars for navigation features, tools, etc.

Indeed. That's where you suffer having only one small screen (as is my current case XD), and where you really appreciate when having dual-screen the ability that some (most nowadays?) editors offer to "extract" some tool menu or information panel as an independant window.

Indeed. Those tools are immensely useful - but they're dumb, doing nothing more than run a pre-programmed set of rules. Any sizable collaborative project should use them, but only under human supervision.

That's sadly too true. In one project I've been working, I made extra efforts to provide as much context as possible in the documentation to keep methods and variable reasonables in name and present all the context assumptions (so that colleagues didn't need to "go up the river" and guess everything by themselves).
Someone runned an automatic "code quality" tool and immediately commited every change.
As a result, the sentences I made with particular care in grammar that allowed a logical flow of one idea per line were ruined, because notably with space indentations (define a class, define a method: you're already 4 characters short at best) the lines were usually around 82-88 characters.

To be fair, the guy that did that never made any effort to respect any kind of code writing standard neither giving any hint on why he wrote some code that way, neither trying to structurate commits to have a stable code state and informative commit logs, and type-hinting and dependency injection were equally impervious to him, so I guess this was expected ("funny" thing is that the guy was viewed as a high-end expert by management and payed golden as such, where I would rather say this was "1st-year student grade" behaviour at best, but well...).

[Delgarde]

That's sadly too true. In one project I've been working, I made extra efforts to provide as much context as possible in the documentation to keep methods and variable reasonables in name and present all the context assumptions (so that colleagues didn't need to "go up the river" and guess everything by themselves).
Someone runned an automatic "code quality" tool and immediately commited every change.

Yes, well... the tools are dumb, but sometimes the people using them aren't much smarter.

[rogerx]

With politics these days, I was expecting a ~5,000 char increase, or something more inline with those whom also write HTML.

[Larry$ilverstein]

Who do you mean exactly by "he" in "his visionary predictions"?

The person I was replying to when you quoted my post. First day on the internet?

[JustRob]

APL coders and Golfers rejoice, a whole program now easily fits on one line.