Changing the code style for new files only is the worst possible idea.
Maintaining two
styles is so bad that I'm surprised that someone even suggested it.
The best decision would be to not change anything in the code style, but if
we
decide to change the style, the entire codebase should be updated. This of
course
raises the problems mentioned above, which is why I think it's best not to
change
the style at all. The current style was chosen by Greg and we should
respect that :)

śr., 19 mar 2025 o 14:05 Nathan Hartman <hartman.nat...@gmail.com>
napisał(a):

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

Reply via email to