Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap

[Sebastien Lorquet]

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