I agree that this change will have an impact, but the discussion here is to decide whether we can switch to a format supported by other linters and code formatters like clang-format or not.
If there is no BUG to be fixed, why are so many people discussing this here? (30+ emails so far). So before making any decision, I suggest we confirm that changing the parentheses indentation from GNU to Altman will make it possible to use clang-format to lint the NuttX code style. If I remember correctly, there are many other coding styles that are exclusive to NuttX, maybe no linter is prepared for NuttX! :-D Luchian, thank you for raising this topic, but I need to warn you to not spend too much time investigating this problem. We had previous examples of people spending a lot for time creating new features to NuttX (i.e. CMakefile, Device Tree) and then some people came here to say it was not necessary. Unfortunately these developers that try to do things like that are skilled developers and we lost them forever. BR, Alan On Wed, Mar 19, 2025 at 12:22 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote: > Hello, > > My feeling is that moving all braces by 2 spaces to the right is not > worth the gigantic mess and maintenance nightmare it will create in the > entire repositories. > > And as noticed by raidenp00l, changing only new files makes no sense > since it means maintaining two different indentation systems. > > The reasonable option is to do nothing at all. > > As of now, indentation works, there is no bug to fix, and changing it > will not improve nuttx. > > Sebastien > > > On 19/03/2025 16:14, Alan C. Assis wrote: > > 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 > >> >
