Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday June 20 2020, @03:04AM   Printer-friendly
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?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Insightful) by Anonymous Coward on Saturday June 20 2020, @03:35AM (6 children)

    by Anonymous Coward on Saturday June 20 2020, @03:35AM (#1010254)

    Long lines suck. Whether 80 chars ought to be the limit is debatable, but there is a reason newspapers do thin columns. Is it really necessary to have function names like eatYourCakeAndMaybeHaveItToo?
    I'd much favor dropping ridiculous quantities of indent to two spaces.

    Starting Score:    0  points
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  

    Total Score:   2  
  • (Score: 4, Interesting) by JoeMerchant on Saturday June 20 2020, @03:38AM (2 children)

    by JoeMerchant (3937) on Saturday June 20 2020, @03:38AM (#1010255)

    Reading a newspaper column is very different from procedural code... quite often code concept align like a table, and laying it out as a table is 200% more readable than following some arbitrary line width rule that has nothing to do with the last two decades of reality.

    --
    🌻🌻 [google.com]
    • (Score: 3, Interesting) by zocalo on Saturday June 20 2020, @08:12AM (1 child)

      by zocalo (302) on Saturday June 20 2020, @08:12AM (#1010304)
      Even then, I'm not sure it's really valid. A shorter line length through columns might actually be more beneficial for avoiding typesetting errors in the the days of actual block type when the typesetter was in a hurry allow the presses to run rather than readability; you could comfortably assemble an entire column width across your palm while pulling blocks from the bins with the other. Printed books of the same era managed much longer lines without significant readability or typographical issues but, of course, they wouldn't have had the same high-pressure deadlines.

      For a data point I just pulled a bunch of random lines of text from the various tabs I currently have open that were long enough to wrap on their own and have a similar presentation to here - e.g. without massive sidebars full of other content - as that is going to be pretty close to what I consider comfortable to read; YMMV. There's still a bit of difference due to layout, what borders they do have, etc. but they're all in the range of 160-180 characters acrosss. This is on a 4K screen though, so the text is very clear (I have about 2x the effective real estate as my 1080p next to it), which is likely to play a significant part in that though.

      For code, yeah, 80 needs to go. No one is printing out code on fan-fold dot matrix printers any more. Whatever works best for a given block of code within reason should be fine - it that's still 80, then so be it - so maybe push it up in the coding style guide to 132 or 160 (the next two commonly supported screen and dot matrix printer widths) and see how it works out?
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 0) by Anonymous Coward on Saturday June 20 2020, @10:02AM

        by Anonymous Coward on Saturday June 20 2020, @10:02AM (#1010312)

        Instead of the number of columns/characters.

        The real problem here is making lines so long they either go off the end of the screen, or code so complex that deciphering it with a careful reading is difficult.

        We already can compact code blocks, so being able to compact elements, but get rid of arbitrary line widths would go a long way to making development cleaner in all but the most badly maintained code.

        Furthermore a good reason for the longer more verbose variable names, is not just for descriptiveness, but also to have a better chance of avoiding a keyword when language revision XY comes out and suddenly decides a bunch of new keywords were needed, one of which was the simple and descriptive variable name you use all over your code and just happened to slip into a few API/ABI calls, which now need to be altered to conform to the new language standards (difficult if not impossible to predict.)

  • (Score: 0) by Anonymous Coward on Saturday June 20 2020, @06:37AM (2 children)

    by Anonymous Coward on Saturday June 20 2020, @06:37AM (#1010290)

    Wide, long, hard.

    Pick 2.

    • (Score: 3, Funny) by kazzie on Saturday June 20 2020, @09:07AM (1 child)

      by kazzie (5309) Subscriber Badge on Saturday June 20 2020, @09:07AM (#1010308)

      We don't want to know about your bedroom habits, thank you.

      • (Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:16PM

        by Anonymous Coward on Saturday June 20 2020, @12:16PM (#1010341)

        Not to worry, he's just coding in bed.