lkml.org 
[lkml]   [2012]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[PATCH] SubmittingPatches: Increase the line length limit from 80 to 100 colums

    * Ingo Molnar <mingo@elte.hu> wrote:

    > > If we want to increase the standard to (say) 96 cols then
    > > fine, I'd be happy with that. But until we do that we
    > > should not create such a gruesome mess for those who use 80
    > > cols.
    >
    > The kernel has *already* become a gruesome mess for 80 col
    > users long ago. That was the main reason why I stopped using
    > 80 col terminals two years ago ...
    >
    > So lets stop the pretense.

    in other words:

    --------------->
    [PATCH] SubmittingPatches: Increase the line length limit from 80 to 100 colums

    The overwhelming majority of kernel developers have stopped
    using 80 col terminals years ago.

    As far as I'm aware I was the last regular kernel contributor
    who still used a standard VGA text console, but both text
    consoles and using them to read the kernel source code has
    become increasingly gruesome years ago so I switched to a wider
    terminal two years ago.

    Worse than that, people are actively uglifying the kernel code
    to fit things into 80 cols mechanically. They are using
    checkpatch and are interpreting the 80 col warnings the wrong
    way again and again, sucking up reviewer bandwidth that could be
    utilized better.

    So lets increase the limit to 100 cols - this is a nice round
    limit, and it also happens to match with most developer xterm
    sizes. Code that goes over 100 cols for no good reasons will be
    arguably something worth fixing. (100 cols is also arguably
    closer to various brain limits such as vision of field and
    resolution restrictions, so we'll likely not have to increase
    this limit for a couple of million years, for all retro human
    genome users.)

    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    ---
    diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
    index 2b90d32..e87370f 100644
    --- a/Documentation/CodingStyle
    +++ b/Documentation/CodingStyle
    @@ -27,7 +27,7 @@ how the indentation works if you have large indentations.

    Now, some people will claim that having 8-character indentations makes
    the code move too far to the right, and makes it hard to read on a
    -80-character terminal screen. The answer to that is that if you need
    +100-character terminal screen. The answer to that is that if you need
    more than 3 levels of indentation, you're screwed anyway, and should fix
    your program.

    @@ -77,11 +77,11 @@ Get a decent editor and don't leave whitespace at the end of lines.
    Coding style is all about readability and maintainability using commonly
    available tools.

    -The limit on the length of lines is 80 columns and this is a strongly
    +The limit on the length of lines is 100 columns and this is a strongly
    preferred limit.

    -Statements longer than 80 columns will be broken into sensible chunks, unless
    -exceeding 80 columns significantly increases readability and does not hide
    +Statements longer than 100 columns will be broken into sensible chunks, unless
    +exceeding 100 columns significantly increases readability and does not hide
    information. Descendants are always substantially shorter than the parent and
    are placed substantially to the right. The same applies to function headers
    with a long argument list. However, never break user-visible strings such as
    @@ -344,8 +344,7 @@ be directly accessed should _never_ be a typedef.
    Chapter 6: Functions

    Functions should be short and sweet, and do just one thing. They should
    -fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
    -as we all know), and do one thing and do that well.
    +fit on one or two screenfuls of text, and do one thing and do that well.

    The maximum length of a function is inversely proportional to the
    complexity and indentation level of that function. So, if you have a
    diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
    index e3bfcbe..2d0f093 100755
    --- a/scripts/checkpatch.pl
    +++ b/scripts/checkpatch.pl
    @@ -1726,15 +1726,14 @@ sub process {
    # check we are in a valid source file if not then ignore this hunk
    next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);

    -#80 column limit
    +#100 column limit
    if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
    $rawline !~ /^.\s*\*\s*\@$Ident\s/ &&
    !($line =~ /^\+\s*$logFunctions\s*\(\s*(?:(KERN_\S+\s*|[^"]*))?"[X\t]*"\s*(?:|,|\)\s*;)\s*$/ ||
    $line =~ /^\+\s*"[^"]*"\s*(?:\s*|,|\)\s*;)\s*$/) &&
    - $length > 80)
    + $length > 100)
    {
    - WARN("LONG_LINE",
    - "line over 80 characters\n" . $herecurr);
    + WARN("LONG_LINE", "line over 100 characters\n" . $herecurr);
    }

    # check for spaces before a quoted newline


    \
     
     \ /
      Last update: 2012-02-03 11:11    [W:0.046 / U:1.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site