On Tue, Jul 24, 2007 at 03:32:59PM -0500, jschopp wrote:
>>> 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.
There's a relatively small amount of common codingstyle mistakes
accounting for most of these mistakes.
> 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.
It's also important to note that there are slightly different
codingstyles in different parts of the kernel, and you won't get people
to agree on one.
A common codingstyle is important, but unifying the last bits is simply
not worth the hassle.
There are more important things than exploiting the corner cases of
codingstyle, e.g. could you teach checkpatch.pl to give exactly two
errors for the following code?
while (a);
for (b = 0; b < 50; b++);
for (c = 0; c < sizeof(struct module); c++)
d = e;
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
