Re: Clang-format configuration discussion - pt 2

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 23 Nov 2023, at 14:47, Luca Fancellu <Luca.Fancellu@xxxxxxx> wrote:
> 
> Hi all,
> 
> Let’s continue the discussion about clang-format configuration, this is part 
> 2, previous discussions are:
> 
> - https://lists.xenproject.org/archives/html/xen-devel/2023-11/msg00498.html
> 
> You can find the serie introducing clang-format here:
> https://patchwork.kernel.org/project/xen-devel/cover/20231031132304.2573924-1-luca.fancellu@xxxxxxx/
> and there is also a patch linked to my gitlab account where you can find the 
> output for the hypervisor code.
> 
> For a full list of configurables and to find the possible values for them, 
> please refer to this page:
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 

[...]

> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> AlignAfterOpenBracket: Align
> 
> ---
> This one is to align function parameters that overflows the line length, I 
> chose to align them
> to the open bracket to match the current codebase (hopefully)
> 
> e.g.:
> someLongFunction(argument1,
>                                 argument2);
> 
> This one can be a candidate for an entry in our coding style
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> AlignArrayOfStructures: Left
> 
> ---
> “When using initialization for an array of structs aligns the fields into 
> columns."
> It’s important to say that even if we specify “None”, it is going to format 
> the data structure anyway,
> I choose left, but clearly I’m open to suggestions.
> 
> I don’t know how to phrase this one in our coding style
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> AlignConsecutiveAssignments: None
> 
> ---
> This one is disabled because of feedbacks from Stefano and Alejandro about 
> some weird behaviour on our
> codebase.
> 
> This one could be phased along this line: “Consecutive assignments don't need 
> to be aligned.”, the issue is
> that in this way it seems that it’s optional, but clang-format is going to 
> remove the alignment anyway for
> assignment that are consecutive and aligned.
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> AlignConsecutiveBitFields: None
> 
> ---
> Same thing as AlignConsecutiveAssignments, but for bitfields.
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> AlignConsecutiveDeclarations: None
> 
> ---
> This aligns declarations names, same considerations as 
> AlignConsecutiveAssignments.
> 
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Ok this is it for now, let me know your thoughts about them, ideally if I 
> don’t get any reply in two weeks (7th of December),
> I will consider that we have an agreement on these configuration.

Hi all,

Just a ping for who wants to say his thoughts about this, Jan already made 
clear his concerns about the lack of flexibility
of the tool, which would provide a default formatting without leaving the 
option to leave the code as it is, making the tool
not fit in his opinion to the use on our codebase.

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, consolidate the style across the codebase.

So, please maintainers, let me know your thoughts on that or please say clearly 
that we are not ready yet to use an
Automatic code style checker.

Cheers,
Luca