[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A661FB.7040504@austin.ibm.com>
Date: Tue, 24 Jul 2007 15:32:59 -0500
From: jschopp <jschopp@...tin.ibm.com>
To: Adrian Bunk <bunk@...sta.de>
CC: Andy Whitcroft <apw@...dowen.org>,
Jan Engelhardt <jengelh@...putergmbh.de>,
Paul Mundt <lethal@...ux-sh.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kok, Auke" <auke-jan.h.kok@...el.com>,
Randy Dunlap <rdunlap@...otime.net>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.08
>> Yep I think the consensus is we need a
>> "--i-don't-agree-just-check-things-which-will-get-me-rejected-out-of-hand"
>> option of some sort which will restrict output to the real errors.
>
> No, the default should be to show only the real errors.
>
CodingStyle violations are real errors.
If we have agreed that code should look a certain way, and there is a patch that doesn't
look that way, that is an error. Maybe not a runtime error, but a readability error. A
reviewability error. A maintainability error. A big waste of everybodies time.
I personally don't care if code is indented with 2 spaces, 4 spaces, or a tab. What I do
care about is that all the code is indented consistently so we don't waste an ounce of our
energy reading code/patches and thinking about indentation or even worse spending our time
arguing over it on mailing lists when there are better things to argue about.
Back when I wrote the early versions of this script I didn't write it because I'm anal
retentive about CodingStyle. I wrote it for the exact opposite reason. I was tired of
seeing email on mailing lists reviewing patches saying there was indentation with spaces
instead of tabs, or trailing whitespace, or { on the wrong line. It was a waste of the
reviewers time, it was a waste of the developers time, it was a waste of the time of
everybody on the mailing lists. We should spend all that energy arguing over the merits
of what the code does.
So let's argue over the CodingStyle once and be done with the argument instead of having
the argument every day on the mailing lists forever. We end up with more time to argue
over much more interesting subjects and we end up with consistent code that is easy to
read, review, and maintain.
-
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