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
Hi Alan,
This discussion did in fact not start from a bug.
It just happens to have some spare time on my hands and I want to work on
something other than embedded.
I fixed some nxstyle bugs previously and saw this opportunity to work with
trees (as in data structure, tree-sitter)
I've started thi
After working in many codebases, I don't really have any preference for a style.
Except that the project should have an autoformatter such as clang-format or
astyle.
Unfortunely the current code style for NuttX is so exotic that no formatter
supports it well.
So, either an autoformatter should b
I agree that this change will have an impact, but the discussion here is to
decide whether we can switch to a format supported by other linters and
code formatters like clang-format or not.
If there is no BUG to be fixed, why are so many people discussing this
here? (30+
emails so far).
So before
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 s
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
Hello,
A change of style, in my opinion, should be started by a maintainer and
agreed by (at least) majority.
The python bindings to tree-sitter allows editing files. I do not intend to
support this feature, but it can be an option for autoformatter.
Cheers, Mihai
On Wed, 19 Mar 2025 at 14:06, P
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
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@nuttx.apache.org
Subject: Re: [EXT] Re
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ł Ł
16 matches
Mail list logo
