On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet <sebast...@lorquet.fr> wrote: (snip)
> Messing *all* developer working copies with huge diffs just for code > formatting is a no-go. This will prevent bissections and backports. This is by far my biggest concern with code style changes. Bissections, backports, comparisons across revisions and across releases, and much more--these things are far, far more important for maintenance and stabilization. Again, I recommend *not* to change code style, and if change must be made to support widely adopted tooling, let's keep it to an absolute minimum, or investigate asking the widely adopted tooling to add support for some of our nuances. Specifically, I am *not* in favor of changing brace style. GNU brace style *is* supported by widely adopted tooling. (I only mentioned K&R to illustrate that if we start debating brace styles, people will come out of the woodwork to promote their favorite style and we'll get nowhere. So far we've heard GNU, Allman, K&R, Whitesmiths... brace styles are one of the holy wars of computing. Let's keep the brace style we've always used in this project and focus on more important things.) Define some relevant rules for new code if you want, but please dont > rewrite the full nuttx codebase just for the pleasure of the eyes (or > the pleasure to use a new toy^H^H^Htool). The problem with defining a new style for new code and keeping the old style for old code is that a 1 line change in a 10,000 line file will mean reformatting the whole file, if we follow the same rules we have now with nxstyle. And we'll have 2 code styles and be inconsistent, so things like editorconfig won't work. Cheers, Nathan
