Then it's settled, Thanks, Mihai
On Wed, 19 Mar 2025 at 15:33, Sebastien Lorquet <sebast...@lorquet.fr> wrote: > Hello > > I admit it was a bad idea. > > What I support is no change at all. > > Also, yeah, it's in the inviolables, thanks for the reminder Greg. > > Sebastien > > > On 19/03/2025 14:23, raiden00pl wrote: > > 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 > >> >
