[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A648C5.5050902@austin.ibm.com>
Date: Tue, 24 Jul 2007 13:45:25 -0500
From: jschopp <jschopp@...tin.ibm.com>
To: Paul Mundt <lethal@...ux-sh.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Whitcroft <apw@...dowen.org>,
"Kok, Auke" <auke-jan.h.kok@...el.com>,
Randy Dunlap <rdunlap@...otime.net>,
Joel Schopp <jschopp@...tin.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.08
<snip>
> checkpatch has been quite useful
> for catching obviously broken things, and now it seems like it's just
> overreaching. Perhaps this functionality can be split in to a lite
> checkpatch for catching show-stoppers for application and then something
> more akin to a CodingStyle validator for the folks interested in
> arbitrarily defining convention, which they can use freely while the rest
> of us try to get something useful done.
CodingStyle isn't about arbitrarily defining convention. It is about making the codebase
consistent, which helps a ton in readability and maintainability.
Readability is important because it makes the job of the maintainers easier. If you or I
have to spend 5 minutes to fix trivial CodingStyle issues, but that 5 minutes saves Andrew
or other maintainers 60 seconds in reviewing your patch, we come out ahead. Anything that
shifts work from maintainers to developers is a good thing because maintainers are
overworked as is.
It could also argue that declaring multiple variables per line or putting curly braces
where they aren't needed doesn't make code unmaintainable. I'd agree any one of these
doesn't make code unmaintainable by itself. But if all these things are added together it
is death by 1000 cuts. The more readable code is the fewer real bugs it will have because
badness stands out more in clean code.
So, no we shouldn't separate out CodingStyle because
Better CodingStyle == less bugs
and
Better CodingStyle == more throughput for maintainers
-
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