Re: Clang-format configuration discussion - pt 2

[Jan Beulich <jbeulich@xxxxxxxx>]

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? I certainly agree that
things would better be written down.

>> 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. 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; whether that's a worthwhile price to pay is
yet to be determined.

Jan