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