Hello, A change of style, in my opinion, should be started by a maintainer and agreed by (at least) majority. The python bindings to tree-sitter allows editing files. I do not intend to support this feature, but it can be an option for autoformatter.
Cheers, Mihai On Wed, 19 Mar 2025 at 14:06, Peter van der Perk <peter.vanderp...@nxp.com> wrote: > After working in many codebases, I don't really have any preference for a > style. > Except that the project should have an autoformatter such as clang-format > or astyle. > > Unfortunely the current code style for NuttX is so exotic that no > formatter supports it well. > So, either an autoformatter should be adapted supporting the NuttX style > features or maybe consider switching code style allowing the use of an > autoformatter, which is still less preferred regarding git history. > > Peter > > -----Original Message----- > From: Sebastien Lorquet <sebast...@lorquet.fr> > Sent: Wednesday, March 19, 2025 11:45 AM > To: dev@nuttx.apache.org > Subject: Re: Re: [PROPOSAL] New nxstyle tool roadmap > > > Hello, > > Great, thank you. > > > At dayjob for 15 years I have used Whitesmiths, which I actually like now > (I resisted at first!), and is the most logical one for me, as the full > sub-block is indented, so it's very readable, almost like python. > My company uses this style for historical and code readability reasons. > > So I have to adapt anyways. A preference would be to avoid a style with > 'half indentations' such as gnu. K&R is fine for me. > > But code compacity is an illusion. Well spaced code is easier to > understand and maintain. > > So Allman would work for me too. > > Sebastien > > > On 19/03/2025 11:14, Luchian Mihai wrote: > > I do not want to change anything, I'm working on a linter. > > It will only *report* noncompliance to a style, not *change* the > > source code. > > The enforcing part should only be imposed by code review, not a tool. > > I'm not a supporter of automatic pipelines either, this compliance > > should be manual work. > > My previous questions were to clarify the community agreed style. > > I aim to improve the existing tooling, with minimal change on the > > actual kernel/apps/c codebase as possible. > > > > On Wed, 19 Mar 2025 at 11:44, Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > >> I will just tell one generic thing: > >> > >> Please just dont push commits just to change the code style globally. > >> What is written is written. > >> > >> Messing *all* developer working copies with huge diffs just for code > >> formatting is a no-go. This will prevent bissections and backports. > >> > >> 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). > >> > >> Sebastien > >> > >> > >> On 19/03/2025 08:43, raiden00pl wrote: > >>> K&R is ugly and unreadable. It will also mess up git history a lot, > >>> so > >> I'll > >>> definitely vote against it. > >>> Allman is much more acceptable, but style change is a significant > >>> change for the project, and there's been a lot of complaining here > >>> lately about "big changes". > >>> > >>> śr., 19 mar 2025 o 02:03 Michał Łyszczek <michal.lyszc...@bofc.pl> > >>> napisał(a): > >>> > >>>> Nathan Hartman: > >>>>> But, if there's going to be a discussion about brace styles, I > >>>>> would > >> vote > >>>>> for K&R's One True Brace Style. :-) > >>>> I agree that K&R is the way to go. But. Switching to Allman is just > >>>> removing > >>>> 2 spaces on lines where bracket is. Change is trivial and will not > >>>> mess with the history. > >>>> > >>>> In theory going to K&R is simple too. Basically same check as with > >> Allman, > >>>> but instead of removing 2 spaces you remove all spaces + previous > >>>> new > >> line > >>>> character. But this will impact history, as all if/for/while will > >>>> have > >> an > >>>> altered line where check is happening. > >>>> > >>>> tl;dr: K&R is more compact, but will mess with history. Allman will > >>>> be > >> just > >>>> as vertically wide as GNU, but will leave history intact where it > >> matters. > >>>> I am down to any change that removes that awful GNU indent :) >
