[libvirt PATCH 0/1] DO NOT MERGE: RFC: targetted usage of clang-format

[Michal Prívozník]

On 11/15/22 11:59, Daniel P. Berrangé wrote:
> While we have a code style, it is not perfectly applied across the code
> base because its impossible for humans to manage that without using
> automated tooling. clang-format is the closest we'll get to a code
> formatter we could use, but still it would reformat quite alot of our
> code.
> 
> I discovered that '/* clang-format off */' can be used to stop it from
> reformatting sections of code. It is not practical to add that comment
> around all places we don't want touched. I thought we could perhaps
> use it as a way to limit clang-format to merely do sorting & regrouping
> of #include statements though.
> 
> This change illustrates what that would look like for the src/util
> directory, so we can consider whuether it is worth it.
> 
> I've included a mark.pl script that I usd to auto-add the magic
> comment. It gets it wrong sometimes, so needs inspection. If we
> did decide to use this, we would need the magic comment in every
> existing source file.
> 
> Then there is the question about new source files. If a contributor
> forgets to add the comment, then entire new source file will be
> processed by clang-format. This might be desirable. If so, we will
> need to fully expand the .clang-format config file to match ou4r
> desired style. Right now I only recorded include file rules.
> 
> Or we could just wrong a dumb script to do #include sorting
> ourselves and carry on ignoring clang-format.
> 
> I'm pretty undecided myself.


I think unsorted #includes are the least offending part. And in fact, I
think mixing their order may hurt our portability. Manpages for some
functions list two includes (though I can't find anything right now).
And not always in alphabetical order. Although, at that point one can
argue if they are order sensitive then it's bug in header files themselves.

IMO we should use an automatic formatting tool. Of course use a
configuration that's as close to our current style as possible. I'm
somewhat reconciled that it will not be 100% match, but if we come up
with good enough .vimrc then I'm good.

Subsequently we ought to make our syntax-check rule required test
(!expensive) and enforce formatting for benefit of new contributors.
They seem to struggle with our somewhat exotic style as I point it out
in my reviews a lot lately.

Michal