Re: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jul 15, 2014 at 09:39:52PM -0700, Joe Perches wrote:
> On Wed, 2014-07-16 at 00:28 -0400, Nick Krause wrote:
> > I am cleaning up the kernel as it needs a lot of cleanup.
> 
> Needs are curious things.
> 
> Consistency is a nicety not really a need.
> 
> Bugs need fixing.  Defects need eliminating.
> Enhancements are appreciated.  Inconsistent
> code style is a minor annoyance.

Note that patches that clean up code style can in fact be actively
harmful, because it interferes with other developers who are sending
patches that fix real bugs and and add new features (because the
cleanups cause patch conflicts).

In general I will ignore patches from people who run checkpatch on
files thinking they are doing me a feature by "cleaning up" the code.
Cleanups as a part of normal code development is fine.

Note also that checkpatch in the past has been at fault for a huge
amount of code churn.  At one point, checkpatch would whine whever
lines were longer than 80 characters, causing people to send huge
numbers of pointles spatch to split printk strings across multiple
lines.  Now, checkpatch whines when it sees character strings that
span multiple lines; so other people will send equally pointless
patches to rejoin those character strings.

In general, checkpatch is good for fixing up patches so that the
maintainer won't complain over stupid nit-picky things.  But fixing
every single nit that checkpatch whines about in a while adds no
value, and in fact, can add negative value.

(Also note that there are some local coding practices where there are
very good reasons why the checkpatch whines need to be completely
ignored.  For example, you checkpatch doesn't deal well with the file
format used in include/tracing/events/*.h.  You need to know when the
right thing to do is to say, "Go home, checkpatch, you're drunk.")

						- Ted