From: Adrian Bunk <bunk@stusta.de>
To: jschopp <jschopp@austin.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>,
Jan Engelhardt <jengelh@computergmbh.de>,
Paul Mundt <lethal@linux-sh.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kok, Auke" <auke-jan.h.kok@intel.com>,
Randy Dunlap <rdunlap@xenotime.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.08
Date: Wed, 25 Jul 2007 03:13:46 +0200 [thread overview]
Message-ID: <20070725011346.GA3572@stusta.de> (raw)
In-Reply-To: <46A661FB.7040504@austin.ibm.com>
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
next prev parent reply other threads:[~2007-07-25 1:14 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 8:25 [PATCH] update checkpatch.pl to version 0.08 Andy Whitcroft
2007-07-23 23:08 ` Kok, Auke
2007-07-24 0:11 ` Randy Dunlap
2007-07-24 9:06 ` Andy Whitcroft
2007-07-24 9:15 ` Andrew Morton
2007-07-24 11:19 ` Andy Whitcroft
2007-07-24 13:08 ` Dmitry Torokhov
2007-07-24 16:51 ` Jan Engelhardt
2007-07-24 17:20 ` Randy Dunlap
2007-07-24 17:46 ` Jan Engelhardt
2007-07-24 18:03 ` Randy Dunlap
2007-07-24 18:30 ` Andy Whitcroft
2007-07-24 17:22 ` Paul Mundt
2007-07-24 18:00 ` Jan Engelhardt
2007-07-24 18:31 ` Andy Whitcroft
2007-07-24 19:49 ` Adrian Bunk
2007-07-24 20:32 ` jschopp
2007-07-25 1:13 ` Adrian Bunk [this message]
2007-07-25 15:39 ` SL Baur
2007-07-25 16:54 ` Adrian Bunk
2007-07-24 18:45 ` jschopp
2007-07-24 19:59 ` Adrian Bunk
2007-07-24 20:53 ` jschopp
2007-07-23 23:13 ` Jesper Juhl
2007-07-23 23:36 ` Kok, Auke
2007-07-24 16:53 ` Jan Engelhardt
2007-07-24 17:06 ` Andy Whitcroft
2007-08-03 12:37 ` Andy Whitcroft
2007-07-23 23:52 ` Kok, Auke
2007-07-24 11:33 ` Andy Whitcroft
2007-07-24 11:47 ` Ingo Molnar
2007-07-24 11:51 ` Ingo Molnar
2007-07-24 16:56 ` Jan Engelhardt
2007-07-24 18:38 ` Andy Whitcroft
2007-07-24 13:58 ` jschopp
2007-07-24 14:33 ` Adrian Bunk
2007-07-24 14:50 ` Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070725011346.GA3572@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=auke-jan.h.kok@intel.com \
--cc=jengelh@computergmbh.de \
--cc=jschopp@austin.ibm.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox