On Tue, Feb 11, 2025 at 09:49:54AM +0000, Luca Fancellu wrote: > Hi Roger, > > >>>> > >>>> 5) You name it. I think many people in the community can name their > >>>> points for > >>>> and against clang-format. > >>> > >>> What are the parts of our coding style that clang-format cannot > >>> correctly represent? Could you make a list of what would need to > >>> change in Xen coding style for it to match perfectly what clang-format > >>> will check? > >> > >> we already went through that route, there is no checker anywhere that > >> matches > >> the Xen coding style perfectly, so it’s either we change the coding style > >> or we > >> don’t proceed further with any automatic check > > > > I'm probably fine with changing coding style, that's why I'm asking > > for a list of what needs to be changed (unless we switch to a > > completely different coding style). > > Sure, I think listing the differences is fine. > > > > >>> > >>> Ideally the first step would be to prepare a patch to adjust the > >>> coding style so it's in line with what clang-format will do. > >> > >> It’s easy to say that, but difficult to implement, if we could accept the > >> clang-format > >> rules it would be easier to adopt the configuration itself as coding > >> style, maybe > >> enhanced with some comments. > > > > I'm kind of lost, why is it difficult to implement? What I'm asking > > for is a patch to CODING_STYLE that modifies it in a way that we could > > use clang-format. In any case we need to do that if we want to use > > clang-format. > > Changes to the CODING_STYLE are historically difficult, given that the natural > language is prone to interpretation. I’m not opposing to that, I’m just > pointing out that > starting changing the CODING_STYLE in order to accept the clang-format feels > more risky and time consuming than testing clang-format and modifying the > CODING_STYLE accordingly.
I suggested that because it's IMO important to see the resulting style. I'm not suggesting to modify CODING_STYLE in a single change, it should be multiple patches that adjust the different areas that require changes to match what clang-format can do. I think it's important that we can see how the final style will look like, otherwise it's hard to compromise on intermediate seemingly unconnected changes without knowing what the end result will be. > Anyway the resulting clang-format would have our coding style for what can be > covered > by the tool and have something new for what it cannot be covered, it’s just > that at least > you have a reproducible way that can be tested. > > > > > One question that seems to have been dropped from my previous email: > > would it be feasible to apply the updated style to newly added chunks > > of code only, but not to the (unmodified) surrounding context? > > I dropped that one from my reply because I know there are tools that do that, > but I’ve never investigated, maybe Oleksandr could try to have a look. > > I’m not sure if the result would feel more like a frankenstein, but it would > for sure > limit the churn. Depends on how many differences there are between our current coding style and what clang-format can enforce that's closer to our existing style. Knowing the differences would be key in understanding whether this would be a viable approach. It would certainly be my preference if the differences between our coding style and what clang-format can do are not too big. Thanks, Roger.
