On Thu, 7 Dec 2023, Julien Grall wrote: > > > > 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
+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 +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. > > I think in this situation is less about moving fast but more about making a > closure of the 3 years+ discussion about the coding style. Exactly. The meeting is useful to find alignment in a more fruitful way. We don't have many MISRA rules left to discuss anyway. We could discuss the codestyle changes after MISRA or in parallel. > We had several persons (including maintainers) expressing there frustration > about the coding style [1]. And this is not really going better... > > We have a couple of solutions: > 1. Properly codify our coding style > 2. Pick an existing one close enough to Xen > > The first one would require the less change in Xen but given nobody really > agree on changes to CODING_STYLE, I feer it is going to take a very long time > to retrofit. From the discussion here, it also seems like we will not be able > to get the automatic checker doing what we want. > > For the second one, this may have an impact on Xen. But it would help to use > an automatic checker. I also don't expect many contributors been able to sink > a lot of time trying to come to a conclusion with the coding style. So I would > chose the least path of resistance which is 2. I believe this is what Luca is > attempting. I also think we need an automatic checker and 2. seems like the best way forward.
