[Libguestfs] [PATCH FOR DISCUSSION ONLY 1/2] scripts: Add a script for formatting all C code in the project.

Richard W.M. Jones rjones at redhat.com
Mon Apr 4 15:51:14 UTC 2016


~~~ Not to be applied, for discussion only ~~~

I think we need some kind of "checkpatch" script to catch all the
annoying, nitpicky code style issues that submitters trip up on.

I looked at a few scripts that exist, primarily the ones from Linux
and qemu (massive and complicated), and libvirt (small and sane).
There are a couple of problems:

(1) Linux/qemu-style checkpatch only verifies new code that is
submitted, leaving the old code in its current, possibly inconsistent
state.

(2) The libvirt one only checks a whitelist of known issues (but
actually, it's still quite a good script).

I thought a different approach might be to run 'indent' across the
whole code base.  As long as we force the indent style settings, and
get submitters and reviews to run the command, then it should ensure
all our code, past and future, has a consistent style.  GNU indent
isn't very good for this, but clang-format is a lot more configurable.

Therefore: the first commit adds a wrapper around clang-format which
runs it with the correct settings, and also does a bit of post-
processing.

Note you need clang-format 3.8.0, currently available in Fedora 24+

The second patch shows the changes that would be made.  It's not too
bad, but there are some problems:

(a) The way struct initializers are formatted is weird.  I'm not even
sure I understand what rules clang is following, since structs get all
sorts of different styles with no rhyme or reason.

(b) It splits up long string constants (although it doesn't resplit
string constants which are already sufficiently split).

(c) It gets horribly confused by our start_element()...end_element()
XML macros.

This doesn't solve the whole problem.  We would still need further
scripts to look for problems such as:

(i) Error messages terminated/not terminated by full stop.

(ii) Not calling reply_with_* functions on error paths.

and so on.

Rich.




More information about the Libguestfs mailing list