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/
: 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, a
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
Message-
> From: Sebastien Lorquet
> 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 act
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
Hi,
I do agree with clang format part, if we are to alter existing style it
will mean to maintain it ourselves, on some codebase that is not nuttx, I
would avoid that.
About the other part, I do not fully agree.
If we take 2019 - 2025 period, Nuttx has changed more than Python. I'm a
new contribu
: [PROPOSAL] New nxstyle tool roadmap
Regarding the missing features in clang format, have you considered opening
feature requests for these with the clang devs?
Regarding a nxtool with multiple subcommands for things, such as style
checking, this is an interesting idea that should be explored
Regarding the missing features in clang format, have you considered opening
feature requests for these with the clang devs?
Regarding a nxtool with multiple subcommands for things, such as style
checking, this is an interesting idea that should be explored.
My only concern is with the addition of
Hello,
I have tried to make a clang format configuration to use, but I have the
same problem where there are a couple style items that clang format has no
options for. Things like enforcing lowercase hex or putting curly braces
indented on a separate line after static initializers.
On Mon, Mar 17
Has anyone looked at using a custom .clang-format file to see if we can get
close to the NuttX style?
I’ve used this route in a couple of projects. I did have to compromise on one
or two rules as I could not get the exact format I wanted. I thought this was
worth it as it saved me writing my
29 matches
Mail list logo
