Re: Clang-format configuration discussion - pt 2

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 7 Dec 2023, Julien Grall wrote:
> > > > Most modern languages, including golang (and I think rust) have
> > > > built-in style correctors (`go fmt` is go's official one).  If you
> > > > haven't worked with an automatic style checker / fixer, you don't know
> > > > how much time, hassle, and emotional energy you're saving.  I don't
> > > > think I know anyone who, after using one, wants to go back to not
> > > > using one any more.
> > > > 
> > > > In general, I'm in favor of making changes to our style such that we
> > > > can make clang's style checker official.  The only reason I would vote
> > > > against it is if one of the style requirements was really intolerable;
> > > > but I find that pretty unlikely.
> > > 
> > > +1

+1


> > > > And as I've said before, the main reservation I have going forward
> > > > with this discussion is that I can't see clearly what it is that I'm
> > > > agreeing to.
> > > 
> > > +1

+1


> > > I found the way we dealt with MISRA rules quite helpful. We had a weekly
> > > meeting to discuss some of the rules and then the outcome was posted on
> > > the ML. Maybe we should do the same here? Any other suggestion how to
> > > move?
> > 
> > I have mixed feelings with meetings like the Misra ones. That's probably
> > unavoidable because of it being a goal to move fast. I'm not sure the
> > same applies here. 
> 
> I think in this situation is less about moving fast but more about making a
> closure of the 3 years+ discussion about the coding style.

Exactly. The meeting is useful to find alignment in a more fruitful way.

We don't have many MISRA rules left to discuss anyway. We could discuss
the codestyle changes after MISRA or in parallel.


> We had several persons (including maintainers) expressing there frustration
> about the coding style [1]. And this is not really going better...
> 
> We have a couple of solutions:
>   1. Properly codify our coding style
>   2. Pick an existing one close enough to Xen
> 
> The first one would require the less change in Xen but given nobody really
> agree on changes to CODING_STYLE, I feer it is going to take a very long time
> to retrofit. From the discussion here, it also seems like we will not be able
> to get the automatic checker doing what we want.
> 
> For the second one, this may have an impact on Xen. But it would help to use
> an automatic checker. I also don't expect many contributors been able to sink
> a lot of time trying to come to a conclusion with the coding style. So I would
> chose the least path of resistance which is 2. I believe this is what Luca is
> attempting.

I also think we need an automatic checker and 2. seems like the best way
forward.