Re: Xen Coding style

[Julien Grall <julien@xxxxxxx>]

On 08/05/2020 09:36, Jan Beulich wrote:
> 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.)
There are existing coding styles that are quite close to the one used by 
Xen (such as BSD). We could either use them as-is or make small changes 
to fit Xen.
> 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).
Consistency is important, but this should not be based on unwritten 
rules. We should be able to write a script that can check whether a 
patch contain any violations.
The end goal is to reduce the workload on the reviewer and the tension 
within the community.
You seem to be the maintainer with the most unwritten rules. Would you 
mind to have a try at writing a coding style based on it?
Cheers,

--
Julien Grall