[Gluster-devel] Coding style and checkpatch.pl

Jeff Darcy jdarcy at redhat.com
Tue Oct 14 15:49:03 UTC 2014

Recently there has been some controversy about the coding style being
enforced by checkpatch.pl since some weeks ago.  Instead of pointing
fingers, I thought it might be useful to get some objective information
that can help us make the situation better.  Accordingly, I ran
checkpatch.pl over our entire current code base (which took quite a
while BTW).  Here are some results.

 * We have ~2.2M lines in 4077 files

 * 457 existing files would have been rejected for style violations

 * There were 13854 errors, plus 7771 warnings

Here are the top ten types of errors.

 * "foo * bar" should be "foo *bar" (4011 places)

 * that open brace { should be on the previous line (2133 places)

 * space(s) required around that $something (1951 places)

 * do not use C99 // comments (1022 places)

 * trailing whitespace (645 places)

 * space prohibited before that close parenthesis ')' (288 places)

 * space prohibited after that open parenthesis '(' (257 places)

 * open brace '{' following struct go on the same line (245 places)

 * space required after that close brace '}' (162 places)

 * "(foo*)" should be "(foo *)" (154 places)

Some of these errors are for things that are common, recommended, or
even required by our coding standard.  Some of them are for things that
are objectively less error-prone than alternatives.  "Brace around
single statement" would have been the perfect example, except that I
already fixed it with http://review.gluster.org/#/c/8813/.  Thus,
developers could be faced with page after page of style errors because
they *copied the style of surrounding code*.  Also, these errors could
cause rejection of a patch just because they appear in the diff context,
and not even in the added/changed lines themselves.

Rejecting patches that consist of 100% style-conformant code seems like
a really excellent way to drive away developers, both old and new.  If
we could change either the script or the existing code to eliminate the
top five or so complaints above, maybe we could avoid that.  Do we have
any volunteers?

More information about the Gluster-devel mailing list