On Wed, Mar 19, 2025 at 9:58 AM Luchian Mihai wrote:
> Hello all,
> First, a few conclusions I've drawn:
> * Keep indent checking fully decoupled, indent style may or may not change
> in future.
> * For the moment we'll keep gnu style. Code style change will have a big
> impact over the code base.
Peter van der Perk:
> The main issue I was facing with clang-format was the indentation with NuttX
> BreakBeforeBraces style see
> https://github.com/llvm/llvm-project/issues/44188
Maybe it's time to say it out loud. GNU indent style for curly brackets
should die ;). Changing these to Allman style
Nutt 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
> Sent: Wednesday, March 19, 2025 6:03 AM
> To: dev
My issues in the past with "pretty printers" were most mostly with C
comments. Most pretty-printers just scramble comments, especially if
they don't understand the comment indentation. NuttX multi-line comments
are not supported by anything AFAIK. And comment information that has a
columnar or
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 read
gt; > >
> > > Alan
> > >
> > >
> > > On Wed, Mar 19, 2025 at 10:24 AM Gregory Nutt
> > wrote:
> > >
> > >> Coding style change are discussed in INVIOLABLES.md:
> > >>
> >
> https://github.com/apache/nuttx/
ote:
> >
> >> 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
> >&g
e/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
From: Nathan Hartman
Sent: Wednesday, March 19, 2025 6:03 AM
To: dev@nuttx.apache.org
Subject: Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap
On Wed, Mar 19, 2025 at 5:45 AM Sebasti
Hello all,
First, a few conclusions I've drawn:
* Keep indent checking fully decoupled, indent style may or may not change
in future.
* For the moment we'll keep gnu style. Code style change will have a big
impact over the code base.
* If it comes to change, Allman is the best candidate, this will
Then it's settled,
Thanks,
Mihai
On Wed, 19 Mar 2025 at 15:33, Sebastien Lorquet
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
] Re: [PROPOSAL] New nxstyle tool roadmap
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet
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
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 th
On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet
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, compari
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
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
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ł Ł
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.
Hi all,
I think we shouldn't make drastic changes to the source style because that
will just create a lot of busywork and a lot of source changes that will
introduce needless headaches when comparing different revisions etc.
Instead, I think we should make only the minimal adjustments to the sour
Hi Michal,
That makes sense, actually I think Altman is similar (but more elegant) to
GNU style:
https://en.wikipedia.org/wiki/Indentation_style
BR,
Alan
On Mon, Mar 17, 2025 at 7:32 PM Michał Łyszczek
wrote:
> Peter van der Perk:
> > The main issue I was facing with clang-format was the ind
To be honest this GNU style is a bit awkward as I tend to use K&R..
but I must admit it is really easy to read and understand when reading
new code.. but NuttX seems to use GNU derivative anyways so no
"generic tools" can be used here and this is the main problem? :-)
https://nuttx.apache.org/docs
Well, this is what I fear, working for something that may change anyway.
I cannot force this change, If we come to an agreement I'll continue the
work I've started, else it is just a waste of time.
Can we make a choice regarding code style?
Cheers,
Mihai
On Tue, 18 Mar 2025 at 00:32, Michał Łysz
The main issue I was facing with clang-format was the indentation with NuttX
BreakBeforeBraces style see
https://github.com/llvm/llvm-project/issues/44188
Regards,
Peter
-Original Message-
From: Nathan Hartman
Sent: Monday, March 17, 2025 2:39 PM
To: dev@nuttx.apache.org
Subject: Re: [
23 matches
Mail list logo
