Re: [PATCH] update checkpatch.pl to version 0.08

[jschopp <jschopp@austin.ibm.com>]

> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/