Message-ID: <20120203100743.GA3334@elte.hu>
Date:	Fri, 3 Feb 2012 11:07:43 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	linux-kernel@...r.kernel.org,
	Pavel Emelyanov <xemul@...allels.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Kees Cook <keescook@...omium.org>, Tejun Heo <tj@...nel.org>,
	Andrew Vagin <avagin@...nvz.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Glauber Costa <glommer@...allels.com>,
	Matt Helsley <matthltc@...ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>, Valdis.Kletnieks@...edu
Subject: [PATCH] SubmittingPatches: Increase the line length limit from 80 to
 100 colums


* Ingo Molnar <mingo@...e.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@...e.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists