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: 4, Touché) by Anonymous Coward on Saturday June 20 2020, @11:27AM (4 children)
If only somebody would come up with some abstract character which represented a level of indentation. Then one could adjust the width of the display layer based on individual preferences.
(Score: 2) by Common Joe on Saturday June 20 2020, @11:32AM (1 child)
I'm all for this for the reason you gave. Unfortunately, it is not the standard that most people want and I am therefore forced to use spaces when I code. I picked on Python in my earlier comment because using 4 spaces (not a tab) is actually part of the Python standard.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:26PM
I like 3 blanks, 4 isover kill.
I also like no more than 4 insets pre line. If you get there, then create a meaningful function blocks and pull the rest into there. Then there are few lines per thought, more high level coding (actual pseudo-code can run!) with meaningful names.
Hell many decades ago, I class project was to change a 20-line BASIC function into Assembler (PDP-11 - the "root" of C). I just did not get my head around that problem, so 1hr before class looked up the MACRO language for the ASM. I wrote a "print", "if", "for", "next" and other BASIC functions in MACROs as needed. Copied and Pasted the BASIC routine in and sent to "compile" and run. Turned that in about 3 mins before class and apologized to the instructor for the number of "pages", he was also my college counselor, and headed to class for the final day. The instructor showed up to class 10 minutes late with a stack of papers and handed out the my solution to class. He copied photo copied my answer and handed it out, then went thought my solution and spend the next hour talking about future of computing and being able to slide between thought patterns and keep ideas tight and clean to present information best for next person to read, see and understand..
PS: As a class we constantly tried to give the tightest code option for the problem. We use number of bytes of ASM to be our "Dutch-Auction". I won or tried many times. But that one, I came in at ~1200 bytes vs ~130 bytes for the "best" one. Learned that day, small tight code is not always the "best" solution.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:36PM
Heretic! at least you didn't say the name of the beast.
Nothing worse than that format method being ported from one system to another (which happens all the time).
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 22 2020, @01:43AM