Hi Alan, This discussion did in fact not start from a bug. It just happens to have some spare time on my hands and I want to work on something other than embedded. I fixed some nxstyle bugs previously and saw this opportunity to work with trees (as in data structure, tree-sitter)
I've started this discussion to make my work visible, and to preempt some changes that I may have not been aware of. Regarding my questions, I like Greg's answer, short, on point answer. "We keep nuttx style, it's in the inviolables." Same applies for my second question (would be useful for nuttx a meta-tool). "Yes" or "Let's try and see" or "No, let's keep scripts independent". Same applies for any other topics we could discuss over my proposal, like choice of programming language. It was never my intention to change anything, any change would have been done at the request/agreement of the community. To be honest, it doesn't matter too much to me the style choice, I like nuttx coding style (it's a trademark / signature) and I also think that it is a better idea to work on our own linter, tree-sitter can make easy work on parsing and checking. Your proposal is also fine, I can alway support it. I fear the problem will be enforcing/agreeing to either choice, the new nxstyle that keeps the old style, or alter the current style. I think the same holds true about any other features you mentioned, maybe this situation can be avoided if some roadmaps can be sketched. A way to express "we are going this direction". Anyway, my conclusion is as follows: I'll continue the work using python and tree-sitter under my initial nxtool proposal. I'll follow the guidelines at contributing / c coding style. We'll see the outcome during code review when a pull request gets opened. Cheers, Mihai On Wed, 19 Mar 2025 at 17:54, Alan C. Assis <acas...@gmail.com> wrote: > 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 > > >> > > >
