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 :)
