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: 3, Insightful) by Common Joe on Saturday June 20 2020, @11:49AM (7 children)
I agree with you in that indenting more than five levels should be rare, but it's hardly unheard of.
By breaking things apart like you suggest, we occasionally lose readability. If we have a very linear computation with multiple input variables used throughout, then by breaking it apart into objects or other subroutines, you lose the ability to see everything in a single view. Yes, it may mean scrolling a little bit, but there is a flip side. I've seen one line subroutines -- as in it has a single if if statement that should have been just put directly put into the method. But I also understand that sometimes you want to read programs on a more abstract level, so one level can help you abstract thought into another level.
I'm also not saying that a long piece of code is correct either. Often times, it is very justified to break it apart for readability and reuseability. It's very dependent on the situation. My big beef on this front is too many people reciting these "rules" without understanding that it's readability that we're after, not "following rules". Following standards is good... until it isn't.
And some things just have no nice way of being programmed. It can be ugly any which way you do it.
Finally, I find too many variables names are too terse. People are afraid to have multi-word variables. They'd rather make an acronym that is only three letters long which I come across later and wonder what it means. (And good luck finding documentation or comments on it.) I often find multi-word variables help readability. A common opinion I receive is that people like reading my methods, but hate writing my variables names. I find that pretty amusing.
(Score: 5, Insightful) by stormwyrm on Saturday June 20 2020, @01:03PM (2 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:16PM (1 child)
Some of us are more human than others.
Most of us forget how we did things just a few years ago and even our own cleverness can be completely opaque if it isn't illuminated somehow.
🌻🌻 [google.com]
(Score: 2, Insightful) by Anonymous Coward on Sunday June 21 2020, @02:13AM
(Score: 4, Funny) by acid andy on Sunday June 21 2020, @10:48AM (3 children)
Yeah code that's very heavily broken into small functions and lots of classes may make it easier to quickly get a high level understanding of it, but it can quickly become very irritating once you have to step through it all just to find whereabouts you need to insert a bug fix or add a feature, unless you wrote it all yourself, that is.
It's become a running joke for example that a lot of enterprise Java code has far too many layers of abstraction chasing too little functionality.
I hate to link to the Other Site (oh forgive me!), but this was posted before ours existed. Someone posted a hilarious enterprise Java version [slashdot.org] of a BASIC one line maze program, which illustrates the issue beautifully!
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by Common Joe on Sunday June 21 2020, @06:39PM (2 children)
I hadn't seen this before. That was hilarious. Thank you for the laugh. I needed that.
And thank you for posting a link that illustrated so beautifully what I was trying to say.
(Score: 2) by acid andy on Sunday June 21 2020, @08:05PM
You're welcome. It was one of the funniest code jokes I'd seen in a long time as well. It was lucky I could remember enough about it to find it in duckduckgo. In the comments someone said it came from reddit.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 1, Funny) by Anonymous Coward on Monday June 22 2020, @01:49AM
See also: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html [ariel.com.au]