Re: [Qemu-devel] [RFC PATCH] Add qemu .clang-format

[Daniel P . Berrangé]

On Wed, Aug 31, 2022 at 05:18:34PM +0800, Wang, Lei wrote:
> 
> 
> On 8/31/2022 4:49 PM, Daniel P. Berrangé wrote:
> > On Wed, Aug 31, 2022 at 02:23:51PM +0800, Wang, Lei wrote:
> > > 
> > > On 10/2/2015 1:30 AM, marcandre.lureau@redhat.com wrote:
> > > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > > 
> > > > clang-format is awesome to reflow your code according to qemu coding
> > > > style in an editor (in the region you modify).
> > > > 
> > > > (note: clang-tidy should be able to add missing braces around
> > > > statements, but I haven't tried it, it's quite recent)
> > > > 
> > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > > ---
> > > >    .clang-format | 6 ++++++
> > > >    1 file changed, 6 insertions(+)
> > > >    create mode 100644 .clang-format
> > > > 
> > > > diff --git a/.clang-format b/.clang-format
> > > > new file mode 100644
> > > > index 0000000..6422547
> > > > --- /dev/null
> > > > +++ b/.clang-format
> > > > @@ -0,0 +1,6 @@
> > > > +BasedOnStyle: LLVM
> > > > +IndentWidth: 4
> > > > +UseTab: Never
> > > > +BreakBeforeBraces: Linux
> > > > +AllowShortIfStatementsOnASingleLine: false
> > > > +IndentCaseLabels: false
> > > 
> > > Hi, any progress on this? I also found a gist on GitHub which can be a
> > > reference: 
> > > https://gist.github.com/elmarco/aa5e0b23567f46fb7f0e73cde586a0c1
> > 
> > clang-format is a great tool and I'd highly recommend its use on
> > any newly started projects, and even retrospectively on existing
> > projects which are small scale. Adding it to large existing projects
> > is problematic though.
> > 
> > None of the QEMU code complies with it today and indeed there is
> > quite a bit of style variance across different parts of QEMU. If
> > we add this config file, and someone makes a 1 line change in a
> > file, clang-format will reformat the entire file contents.
> > 
> > The only practical way to introduce use of clang-format would be
> > to do a bulk reformat of the entire codebase. That is something
> > that is quite disruptive to both people with patches they're
> > working on but not submitted yet, as well as people wanting to
> > cherry-pick new commits back to old code branches.
> > 
> > With regards,
> > Daniel
> 
> I think the benefits of introducing clang-format mainly for its ability to
> format a code range, which means for any future contributions, we could
> encourage a range format before the patch is generated. This can extensively
> simplify my workflow, especially because I use the Neovim + LSP combination,
> which supports a built-in function "lua vim.lsp.buf.range_formatting()".

IMHO partial format conversions are even worse than full conversions,
because they would make code inconsistent within the scope of a file.

> I have no interest in reformatting the existing code and also think using it
> to reformat an entire file shouldn't be encouraged, but, we can leverage
> this tool to give future contributions a better experience. It's also
> important to note that the kernel already has a ".clang-format" file, so I
> think we can give it a try:)

The mere action of introducing a .clang-format file in the root of the
repository will cause some contributors' editors to automatically
reformat files every time they are saved. IOW even if you don't want
intend to do reformatting, that will be a net result.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|