Re: Clang-format configuration discussion - pt 2

[Julien Grall <julien@xxxxxxx>]

Hi,

On 07/12/2023 07:28, Jan Beulich wrote:
> On 06.12.2023 18:55, Julien Grall wrote:
> > On 06/12/2023 02:32, George Dunlap wrote:
> > > On Tue, Dec 5, 2023 at 2:07 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > > > On 05.12.2023 14:46, Luca Fancellu wrote:
> > > > > In my opinion, I don’t know of any tool that can address all the flexibility 
> > > > > the Xen codestyle allows, yet the use of automatic
> > > > > checkers would improve the review time, allow more new contributors to approach 
> > > > > the community without being put down by
> > > > > the amount of code-style comments,
> > > > Since this argument is being repeated: I find it odd. No-one needs to even
> > > > fear any amount of style comments if they simply follow the written down
> > > > policy plus a tiny bit of common sense. According to my observation, (some)
> > > > newcomers don't even care to look at what is being said about our style.
> > > > It's not like you and I haven't been through this. When I started working
> > > > with GNU toolchain, I had to adopt to their style. When I later started to
> > > > work with Linux, I had to also adopt there. And then for Xen. And all of
> > > > that already past closed source projects I had been working on before.
> > I am not sure I get the point. With this argument, we are not only
> > putting load on the contributors but also on the reviewers because we
> > have to check the style manually while reviewing the code.
> >
> > Do you really think this is a good use of our time? Personally I don't
> > think so and definitely there are more unwritten rule than you let
> > transpire above.
> >
> > A good example is the "_" vs "-". If even a maintainer can't guess it,
> > then how can a contributor know it?
> I didn't even hint at anything unwritten, did I?
You didn't and that was my point. I don't think we can put the unwritten 
rules aside when arguing about how easy it is to follow our coding 
style. They are usually the ones that tends to be the most contentious 
and trigger the most debate everytime they come up...
> > > 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
> >
> > > 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
> >
> > 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.
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.
> But first of all - see also what George said - there
> needs to be a coherent proposal of what aspects of style to change in
> which way. The more heavy the changes, the harder it may be for long
> time contributors to adapt;
The whole point of having an automatic coding-style checker/formatting 
is you don't need to worry about it anymore.
Obviously if you intend to avoid the coding style checker, then it will 
be more difficult...
Cheers,

[1] 
https://lore.kernel.org/all/CABfawhnaDS=nGn3+NqoY_nWXvu0cfsAmpYjiv9VqkT6C0Ow1FA@xxxxxxxxxxxxxx/
--
Julien Grall