But changing from GNU to Altman (removing 2 "half" indentation spaces) could fall on this category:
``No "revolutionary" changes to the coding standard (but perhaps some "evolutionary" changes).'' BR, Alan On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt <spudan...@gmail.com> wrote: > Coding style change are discussed in INVIOLABLES.md: > https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style > ________________________________ > From: Nathan Hartman <hartman.nat...@gmail.com> > Sent: Wednesday, March 19, 2025 6:03 AM > To: dev@nuttx.apache.org <dev@nuttx.apache.org> > Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap > > 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 >
