Language Selection

English French German Italian Portuguese Spanish

The Linux Kernel Deprecates The 80 Character Line Coding Style

Filed under
Linux

The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit".

The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be as enforced.

This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals but with today's high resolution displays the terminal sizes are often larger though some preferring the default in order to allow more terminals to be displayed simultaneously on their nice displays.

Read more

Original from Torvalds:

  • clean up kernel_{read,write} & friends v2
    Not necessarily.
    
    Excessive line breaks are BAD. They cause real and every-day problems.
    
    They cause problems for things like "grep" both in the patterns and in
    the output, since grep (and a lot of other very basic unix utilities)
    is fundamentally line-based.
    
    So the fact is, many of us have long long since skipped the whole
    "80-column terminal" model, for the same reason that we have many more
    lines than 25 lines visible at a time.
    
    And honestly, I don't want to see patches that make the kernel reading
    experience worse for me and likely for the vast majority of people,
    based on the argument that some odd people have small terminal
    windows.
    
    If you or Christoph have 80 character lines, you'll get possibly ugly
    wrapped output. Tough. That's _your_ choice. Your hardware limitations
    shouldn't be a pain for the rest of us.
    
    Longer lines are fundamentally useful. My monitor is not only a lot
    wider than it is tall, my fonts are universally narrower than they are
    tall. Long lines are natural.
    
    When I tile my terminal windows on my display, I can have 6 terminals
    visible at one time, and that's because I have them three wide. And I
    could still fit 80% of a fourth one side-by-side.
    
    And guess what? That's with my default "100x50" terminal window (go to
    your gnome terminal settings, you'll find that the 80x25 thing is just
    an initial default that you can change), not with some 80x25 one. And
    that's with a font that has anti-aliasing and isn't some pixelated
    mess.
    
    And most of my terminals actually end up being dragged wider and
    taller than that. I checked, and my main one is 142x76 characters
    right now, because it turns out that wider (and taller) terminals are
    useful not just for source code.
    
    Have you looked at "ps ax" output lately? Or used "top"? Or done "git
    diff --stat" or any number of things where it turns out that 80x25 is
    really really limiting, and is simply NO LONGER RELEVANT to most of
    us.
    
    So no. I do not care about somebody with a 80x25 terminal window
    getting line wrapping.
    
    For exactly the same reason I find it completely irrelevant if
    somebody says that their kernel compile takes 10 hours because they
    are doing kernel development on a Raspberry PI with 4GB of RAM.
    
    People with restrictive hardware shouldn't make it more inconvenient
    for people who have better resources. Yes, we'll accommodate things to
    within reasonable limits. But no, 80-column terminals in 2020 isn't
    "reasonable" any more as far as I'm concerned. People commonly used
    132-column terminals even back in the 80's, for chrissake, don't try
    to make 80 columns some immovable standard.
    
    If you choose to use a 80-column terminal, you can live with the line
    wrapping. It's just that simple.
    
    And longer lines are simply useful. Part of that is that we aren't
    programming in the 80's any more, and our source code is fundamentally
    wider as a result.
    
    Yes, local iteration variables are still called 'i', because more
    context just isn't helpful for some anonymous counter. Being concise
    is still a good thing, and overly verbose names are not inherently
    better.
    
    But still - it's entirely reasonable to have variable names that are
    10-15 characters and it makes the code more legible. Writing things
    out instead of using abbreviations etc.
    
    And yes, we do use wide tabs, because that makes indentation something
    you can visually see in the structure at a glance and on a
    whole-function basis, rather than something you have to try to
    visually "line up" things for or count spaces.
    
    So we have lots of fairly fundamental issues that fairly easily make
    for longer lines in many circumstances.
    
    And yes, we do line breaks at some point. But there really isn't any
    reason to make that point be 80 columns any more.
    
                      Linus
    

Now in Slashdot

  • Linus Torvalds Argues Against 80-Column Line Length Coding Style, As Linux Kernel Deprecates It

    "Yes, staying withing 80 columns is certainly still _preferred_," notes the official commit message for this change. "But it's not the hard limit that the checkpatch warnings imply, and other concerns can most certainly dominate. Increase the default limit to 100 characters. Not because 100 characters is some hard limit either, but that's certainly a 'what are you doing' kind of value and less likely to be about the occasional slightly longer lines.'"

80-characters-per-line limits should be terminal...

  • 80-characters-per-line limits should be terminal, says Linux kernel chief Linus Torvalds

    Linux kernel overlord Linus Torvalds has railed against 80-character-lines as a de facto programming standard and has moved to make reminders to keep things short a thing of the past.

    Torvalds weighed in on a Linux kernel clean-up post that somehow strayed into the topic of line lengths. Some advocated for the retention of 80-character lines on grounds that they're a long-standing convention and that large monitors can handle many small windows when column width is limited.

    Torvalds respectfully disagreed on grounds that limiting lines to 80 characters makes for lots of line breaks.

    "Excessive line breaks are BAD. They cause real and every-day problems," he wrote.

    "They cause problems for things like 'grep' both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based."

Video about this

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Android Leftovers

LibreOffice 6.4.5 Released with over 100 Bug Fixes, Now Ready for Enterprise Deployments

LibreOffice 6.4.5 comes one and a half months after LibreOffice 6.4.4 and it’s packed with lots of bug fixes across all core components. A total of 106 bugs have been addressed in this new point release, as documented here and here. But, the good news that I would like to share with you today is that the LibreOffice 6.4 office suite series is now finally ready for enterprise deployments in production environments as it’s thoroughly tested and includes several months of bug fixes. Those of you using the LibreOffice 6.3 office suite series in enterprise environments should upgrade to LibreOffice 6.4.5 as soon as possible. You can download the latest release for Linux, Mac, and Windows platforms right now from the official website. Read more

Ubuntu 19.10 (Eoan Ermine) Will Reach End of Life on July 17th, 2020

Launched last year on October 17th, Ubuntu 19.10 (Eoan Ermine) shipped with the Linux 5.3 kernel series, the GNOME 3.34 desktop environment, initial support for ZFS as the root file system via the installer, support for DLNA sharing, WPA3 support, as well as Yaru light and dark themes. Since it’s not an LTS (Long Term Support) release, Ubuntu 19.10 was mainly a testbed for Canonical to try new features. This also translates to the release not having any major changes and receiving only 9 months of support. Therefore, on July 17th, 2020, Canonical will no longer support Ubuntu 19.10. This means that they will cease to provide software updates and security fixes for the distribution. Read more

today's leftovers

  • Getting started on your SAP HANA journey with RHEL 8 for SAP Solutions

    Red Hat Enterprise Linux (RHEL) 8, which was released at the Red Hat Summit in May 2019, can provide significant performance improvements across a range of modern workloads.  As of March 31, 2020, SAP officially announced the support for SAP HANA 2.0 on Red Hat Enterprise Linux 8.1 for SAP Solutions on Intel 64 and IBM POWER9 architectures.  With this offering, SAP HANA is fully certified and supported on Red Hat Enterprise Linux 8.1 for SAP Solutions as documented in SAP notes 2777782 and 2235581. Beyond the benefits provided by the latest version of the world’s leading enterprise Linux platform, RHEL 8 for SAP Solutions offers the following components...

  • CI/CD with OpenShift
  • Red Hat Audit to ‘Eradicate’ Problematic Language in Its Code

    Red Hat has become the latest software company pledging to remove "problematic" language from its platforms. In a blog post published to the company’s website, Chief Technology Officer Chris Wright said the company would be “standing up a team to audit our own work—our code, documentation and content—and identify potentially divisive language.” “When we looked at why certain words are still being used in open source, we questioned why they persisted and what we could do about it,” Wright told Motherboard in an email.        

  •         
  • System Configuration Proc File System
  • Install VirtualBox 6.1 on Oracle Linux 8
  • Install VirtualBox 6.1 Extension Pack on Oracle Linux 8
  • An Easy Introduction to Open Source Projects

    So what is an open source project anyway? It seems like the answer should be easy. “It's openly available code,” right? Well, not necessarily. It all depends on how the project is licensed. A license tells other people what they can and cannot do with a project. A project like Unity is openly available but its license states it’s only available for reference, not for modification or redistribution. Other projects are openly available but have no license at all. According to copyright law, this means the project is automatically all rights reserved, meaning it’s illegal to do anything at all with the project without the author’s express permission. Neither of these examples are open source projects, because neither of them are licensed in a way that’s in accordance with the Open Source Definition (OSD). This is a set of 10 requirements that a project must meet to be considered “open source.” If a project doesn’t meet each one of those 10 requirements, it violates the OSD and, by definition, is not an open source project. The easiest way to make sure a project is actually open source is to look at the license under which it’s released. If it’s an Open Source Initiative-approved license, then you're guaranteed that the project meets all 10 of the requirements of the OSD and is definitely an open source project. That’s because the Open Source Initiative (OSI), the standards body that maintains and protects the OSD, has reviewed those licenses and confirmed that any project that uses one of them will provide the 10 requirements of the OSD. Projects that use a different non-approved license or no license at all cannot be guaranteed to be open source and may be risky or even illegal to use. Some popular OSI-approved licenses include GNU General Public License GPL, Apache License 2.0, MIT license, and the suite of Creative Commons licenses. [...] Some people contribute because they believe in the Four Freedoms and the power that these freedoms have to foster equality and equity for all people. Whatever reasons you have for wanting to contribute, always remember that’s exactly what those reasons are: yours. No one else will have the same needs, goals, or constraints. Your reasons are unique and personal.

  • We don't really own the digital possessions that we buy online

    The popularity of access-based consumption has obscured the rise of a range of fragmented ownership configurations in the digital realm. These provide the customer with an illusion of ownership while restricting their ownership rights. Companies such as Microsoft and Apple present consumers with the option to “buy” digital products such as eBooks. Consumers often make the understandable assumption that they will have full ownership rights over the products that they pay for, just as they have full ownership rights over the physical books that they buy from their local bookstore.

    However, many of these products are subject to end user licence agreements which set out a more complex distribution of ownership rights. These long legal agreements are rarely read by consumers when it comes to products and services online. And even if they do read them, they are unlikely to fully understand the terms.

    When purchasing eBooks, the consumer often actually purchases a non-transferable licence to consume the eBook in restricted ways. For instance, they may not be permitted to pass the eBook on to a friend once they have finished reading, as they might do with a physical book. Also, as we have seen in the case of Microsoft, the company retains the right to revoke access at a later date. These restrictions on consumer ownership are often encoded into digital goods themselves as automated forms of enforcement, meaning that access can be easily withdrawn or modified by the company.