Re: Xen Coding style

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.05.2020 16:43, Julien Grall wrote:
> This was originally discussed during the last community call.
> 
> A major part of the comments during review is related to coding style issues. 
> This can lead to frustration from the contributor as the current CODING_STYLE 
> is quite light and the choice often down to a matter of taste from the 
> maintainers.
> 
> In the past, Lars tried to address the problem by introducing a coding style 
> checker (see [1] and [2]). However, the work came to stop because we couldn't 
> agree on what is Xen coding style.
> 
> I would like to suggest a different approach. Rather than trying to agree on 
> all the rules one by one, I propose to have a vote on different coding styles 
> and pick the preferred one.
> 
> The list of coding styles would come from the community. It could be coding 
> styles already used in the open source community or new coding styles (for 
> instance a contributor could write down his/her understanding of Xen Coding 
> Style).
> 
> Are the committers happy with this appraoch?

I'm not, sorry, and I'm pretty sure I indicated so before. For one I
don't think picking an arbitrary other style than what we currently use
is going to be helpful: It'll be a significant amount of code churn all
over the code base. Instead I think the basic current principle should
remain: Imported files, if not heavily changed, are permitted to retain
their original style, while "our" files get written in "our" style.
(Recording which one's which is still tbd.)

I don't think though this necessarily implies "to agree on all the rules
one by one" - we could also settle on there explicitly being freedom
beyond what's spelled out explicitly. I'd not be happy with this, as it
would lead to a lot of inconsistencies over time, but it's still an
option. Obviously there's the wide range of middle ground to agree on
some more rules to become written down (I did propose a few over time,
without - iirc - getting helpful, if any, feedback), while leaving the
rest up to the author.

The main thing we need to settle on imo is whether unwritten rules
count. Me being picky isn't because of me liking to be, but because of
me thinking that a consistent code base is quite helpful. If consensus
is that consistency is not a goal, I'll accept this (with some
grumbling).

Jan