[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xen Coding style

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 

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 

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

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?


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.