checkpatch.pl: remove the 80 charactes punch card limit

The time of 80 characters punch card and terminals are over, so i would be a good thing to set the line length limit to 120. Every display today should be able handle this.

---
 checkpatch.pl |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

@@ -1374,13 +1374,13 @@ 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
+#120 column limit
 		if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
 		    $rawline !~ /^.\s*\*\s*\@$Ident\s/ &&
 		    $line !~ /^\+\s*printk\s*\(\s*(?:KERN_\S+\s*)?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ &&
-		    $length > 80)
+		    $length > 120)
 		{
-			WARN("line over 80 characters\n" . $herecurr);
+			WARN("line over 120 characters\n" . $herecurr);
 		}
 
 # check for adding lines without a newline.

Nack.

While the origins of 80 character lines dates back to punchcards there is a reason it has survived the test of time. Lines that go longer are hard to comprehend. Either they are long themselves, in which case breaking them up into smaller chunks on multiple lines helps readability, or they are starting from deep indentation, in which case the function should be refactored or broken up so the logic is more digestable.

Has it though? If that were the undisputed truth, we wouldn't be having this discussion. Also it is likely that there would be very few devices capable of displaying more than 80 columns.

Not universally.

... Or sometimes it results in gibberish.

The problem with the checkpatch.pl tool is that its use results in people trying to eliminate warnings. In the case of the 80 column warning, this can result in going against the goal stated in CodingStyle Chapter 2: "Coding style is all about readability and maintainability..."

Perhaps checkpatch.pl needs a third level of diagnostic. Perhaps:

NOTICE: line over 80 characters

Indicating that the line in question should be given extra attention, but weaker than a WARNING.

In any event, it is always fun to discuss these questions of style.

David Daney

If you know of a usability study that quantifies the effect of line length on readibility of C code I'm willing to listen, and I'm sure others are too.

Good point. As with most things related to kernel development, a usability study or other market research from a reputable institution is a vital first step before taking any action.

We don't have any good peer reviewed research on the subject that I am aware of. I guess even contemplating a change at this early point would be rash and dangerous.

I withdraw my previous comments with respect to the 80 Column Question.
Instead I would recommend elevating the WARNING to ERROR status.

David Daney

Am Mittwoch, den 27.01.2010, 14:31 -0600 schrieb Joel Schopp:

Show me the usability study with claims that 80 columns is the wisdom in software engineering. Why not 73, 90 or 95? The only reason for the 80 columns is a historic one.

And the programming rules for linux doesn't manifest the 80 character per line.

Code will get in many cases harder to read, especially together with the tab size of 8. Multiline C statements makes the code IMHO harder to read.

Stefani

Full Ack!

-Andi

[email protected] -- Speaking for myself only.

I thought it's been already agreed that the limit is lifted altogether? Not even the 132 that was considered by some people sane enough.

The other thing is that fine "code complexity", but I think checkpatch can't check it ATM, can it?

Krzysztof Halasa

I agree, but if people still have problems with it, perhaps reevaluating Joe Perches' patch:

http://lkml.org/lkml/2009/12/18/3

could be an alternative.

David Daney

NACK Attack!

There is a reason Knuth only put so many words on a line with TeX.

Eugh.

Cheers

Alexander Clouter
.sigmonster says: Keep out of reach of children.

Linus has already agreed that the 80 character limit is stupid. Let's just nuke this check from checkpatch.pl and move on.

- Ted

Andy, can you update checkpatch please?

I proposed this: http://lkml.org/lkml/2009/12/18/3

If you're too busy, I can collect the several
additional patches that have been suggested and
push them to you or to Andrew Morton.

If you're going to cite Knuth as a reason for the 80 character per line limit, you should understand the difference between ribbon length and line length.

While there are good reasons to constrain the number of characters in a ribbon, and to prohibit too much of a shift in indentation between two neighbouring lines, there's no particularly strong readability reason to limit a line to 80 characters.

Thus, assuming that maintainers read the patches they're sent, and apply a bit of common sense (insisting on sensibly sized ribbons, and getting grouchy about deep indentation), an 80 character line length limit isn't needed.

Simon