SoylentNews is people
SoylentNews
from the depends-on-whether-you-code-using-emacs-or-vim? dept.
Are 80 Characters Per Line Still Reasonable In 2020?
[...] In case of the Linux kernel, that's of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.
[Linus]' reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won't serve much use in kernel development anyway.
Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn't call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?
The article then gives an overview of the history of how 80 columns became the de facto standard width. Though mentioned briefly in passing, it all really got started with the invention of the punched card dating back to 1804 when "Joseph Marie Jacquard demonstrated a mechanism to automate loom operation". The physical size of the punch card used in the 1890 United States Census was the same as US currency at that time. The cards were then known as "Hollerith cards" after the inventor Herman Hollerith. Later, IBM came to dominate the field.
As technology progressed, punch cards eventually gave way to computer terminals such at the IBM 3270 and "glass TTYs" like the DEC VT05 and Lear Siegler ADM-3A.
Computer languages were even designed around that common size. Both FORTRAN and COBOL had fixed line layouts with certain columns reserved for such things as sequence numbers, comment indicator, continuation marker, as well as the code itself.
Human factors play a role, too. A newspaper could, for example, have lines of text as long as the page is wide. It was found to be difficult to connect visually where the next line would start when one reached the end of a physical line. Hence multiple columns of text on a page. The same often holds for magazines, too.
Back to the question at hand.
I have personally used punch cards, FORTRAN, COBOL, and all of the computer terminals listed. I generally aim for 80-columns in the code I write, but I am flexible about it. Should I find that 90-100 columns better allows me to express and comprehend the code I've written, I'll err on the side of using more columns. A quick look through some code I've written revealed one case where I used 132 columns.
What about you? Hard and fast limit of 80 columns and not a single column more? 80-90? 100? Whatever it takes? Where and how do you draw the line?
(Score: 5, Insightful) by JoeMerchant on Saturday June 20 2020, @03:21AM (6 children)
Nothing wrong with how Linus expresses himself - abrasive is O.K. for somebody with his position/role.
80 character lines are needlessly restrictive, and have been ever since 1920x1080 monitors became a de-facto standard (and actually long before that too.)
It causes problems with grep, it causes problems with descriptive variable names, it causes problems with basic readability of code, and anybody who doesn't see the obviousness of that can go back to their punch card machines and wring their hands for a few more years about backward compatibility - the rest of us won't even miss you.
🌻🌻 [google.com]
(Score: 3, Insightful) by Anonymous Coward on Saturday June 20 2020, @05:01AM (3 children)
It is rather unnatural feeling to read stuff near the right side of a too-wide window. In my browser, I use an extension with window-resizing function to keep it at a sensible width most of the time.
Given that I use 19 pt font in my code editor (I do not have a spare set of eyes, do you?), keeping code at under 80 chars width is sensible for the same reason.
However, as Linus said, 80 is not a hard limit anymore, and a linebreak to split a mere 86 char line in two is indeed a silly one. 100 or 110 chars is no problem either, if the line is better left unbroken for some reason.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:17PM
Apparently I do, because I read screen wide texts all the time, and it works wonderfully for me. Maybe it's just you.
(Score: 1, Insightful) by Anonymous Coward on Saturday June 20 2020, @04:08PM
exactly my feeling as well, but an observation;
The closer to the hardware - the more preferance for the old short form.
Which makes sense to me because someone who might have to debug on actual equipment wouldn’t want the hassle
(Score: 2) by driverless on Sunday June 21 2020, @02:58AM
Going to 100, or a soft increase on 80, so 80 if possible but up to 100-110 if it would make the code look messy, is fine. However allowing infinite-length lines makes code really difficult to read, I'd rather have an excessively-complex expression on one line broken down into a few logical blocks over several lines than have to try and interpret a 300-character line that scrolls off the right of the monitor. Soft-80 is probably the best compromise between readability and displaying stuff appropriately.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @05:28PM (1 child)
yeah, i never have followed any stupid restriction of my char length. I base it on what's reasonable for my monitor. If the reader has a vastly different sized monitor, i don't really give a shit.
(Score: 3, Informative) by https on Saturday June 20 2020, @10:34PM
I really don't want a subordinate with this attitude ("works for me, wontfix") wasting other of my subordinates' time on a project. You erase value.
Offended and laughing about it.