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) by maxwell demon on Saturday June 20 2020, @05:18AM (3 children)

    by maxwell demon (1608) on Saturday June 20 2020, @05:18AM (#1010281) Journal

    I don't like the left-ragged types, nor the split-off commas or closing parenthesis.
    What's wrong with the following?

    -ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
    +ssize_t __kernel_write(struct file *file,
    +                       const void  *buffer,
    +                       size_t       count,
    +                       loff_t      *position)

    --
    The Tao of math: The numbers you can count are not the real numbers.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Funny) by Anonymous Coward on Saturday June 20 2020, @06:40AM (1 child)

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

    I get the impression of violinists contrasting techniques on the deck of the Titanic.

    • (Score: 2) by maxwell demon on Saturday June 20 2020, @11:03AM

      by maxwell demon (1608) on Saturday June 20 2020, @11:03AM (#1010319) Journal

      I don't see the set of languages with C-like function declarations to be sinking any time soon.

      Languages with mostly this style of declaration include

      • C (of course) and C++ (obviously).
      • Java and C#
      • D
      • Raku (formerly known as Perl 6) when using the optional static typing

      Languages with function declaration similar to Pascal-style (basically C style with order of type and name reversed) include

      • Swift
      • Rust
      • Go
      • Scala

      These lists are not claimed to be anywhere near complete. Note that I omitted languages that are mostly or completely obsolete.

      Indeed, I expect the majority of new languages, whenever they include mandatory or optional static typing, to roughly follow either a C style or a Pascal style function declaration (the third option would be a Fortran style declaration, but I think that one has fallen out of favour a long time ago).

      --
      The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 2) by JoeMerchant on Saturday June 20 2020, @12:10PM

    by JoeMerchant (3937) on Saturday June 20 2020, @12:10PM (#1010335)

    Matter of preference - I prefer the type to be closer to the variable it applies to.

    The split-off commas are an acquired taste which can be more palatable in larger table like structures - particularly sparse ones where they help identify a pattern that's not 100% consistent.

    Spaces after the parenthesis: I like to alternate those, makes it easier to identify matching open and closes if they have matching space or no space. I generally start with a space ( makes it easier to read the enclosed text (but it's a small thing) ).
     

    --
    🌻🌻 [google.com]