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: 1) by bloodnok on Saturday June 20 2020, @06:19PM (3 children)
I think a better way to look at this is what is the advantage of longer line lengths?
I try to write within 80 columns but I'm not obsessive about it. If a statement cannot be reasonably formatted to fit in 80 columns, I let it it go over.
The only consideration should be: is the code readable? And if you're working in a team that has to mean is it consistent with the code that has gone before.
The times that I find long lines irritating are when there is more indentation than code, or when I cannot read a line without having to scroll sideways, or expand the window so much that I can't have multiple windows open side by side.
80 columns is, these days, an arbitrary limit. But so is any other limit. For me, 80-columns works just fine and other developers seem to have no problems reading my code.
Allowing longer lines as the norm just means that you've moved the line-wrapping problem to the right: it doesn't, in itself, solve anything. Coding is a discipline. Making your code readable and consistent is an act of discipline and a sign of respect to your colleagues who may have to read and fix it.
In the past I've had disagreements with other developers about this. They would usually show me a section of their code which "required" more than 80 columns. I have always been able to reformat such code to make it fit, and be, to me at least, more readable. And at that point I always gave up the fight because the piece of code that I'd modified was now the only part of their code that I could easily read. Making one part carefully and thoughtfully structured would provide such a contrast with the rest of their code that the whole thing looked like crap.
In my projects I will continue to require 80 columns as an advisory limit. I believe there has to be a limit and 80 columns allows me to use 2 editor windows side by side on my laptop. Paradoxically, allowing wider lines forces me into a mode of working which is much more like the VT-100 days as I have to either give up the utility of multiple windows, or give up on seeing whole lines of code.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:18PM (2 children)
For me, it's patterns. When the code is doing a bunch of nearly redundant stuff, like hooking up properties to UI elements, or somesuch. If each line can represent one of the nearly identical steps, that table of code is much easier to read than two or three lines doing each step over and over. Variations in the pattern, intentional or unintentional, show up much faster in table form.
🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:23PM (1 child)
as opposed to:
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @11:32PM
Just put a blank line in between the groups of related statements and there is no readability problem