On 26.07.23 17:17, Gedare Bloom wrote:
On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 25.07.23 23:41, Gedare Bloom wrote:
I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).
A few things to note:
* We can always manually override style with good reason. If you see
something like that in a patch, please let me know.
* I have started to avoid changing the __asm __ ... blocks, as
clang-format doesn't do a great job with those at the moment.
* clang-format also doesn't know how to indent broken if/for loops
like we prefer. So i may need to continue manual intervention on those
until I can get around to teaching it how. I believe that is doable,
but will take me some time to implement and get upstream.
* clang-format also has a preference to break function declarations
differently than we do. It will prefer to break after the function
return type/decorators, rather than in the parameter list. This may be
something we can tune. For now, I fix this manually.
I may prepare a few more patches tomorrow, but I will leave these two
for the time being for feedback.
Thanks for the samples. A good test file is
cpukit/score/src/threadqenqueue.c.
In the samples, there are a lot of changes in everything involving ()
and []. I think we should either
* aim for a configuration which performs a minimum set of changes in
files which are close to the existing score style, or
* choose a standard style.
I agree. i think I can get clang-format closer to that "minimum set"
but it seems to require still a few more modifications upstream.
Regarding spaces in [], I analyzed the score and found it was not
consistent, but more of the time there were not spaces:
$ grep -r "\[[^[:space:]]" | wc
2615 17577 191765
$ grep -r "\[[[:space:]]" | wc
223 1509 16393
You have to look also at the files and not just the overall count. The
[x] style is mostly used on files outside the original score (newer
contributions, CPU ports, BSD sources).
The style guide doesn't cover the [] explicitly, but I think we should
just apply the rules for ():
https://docs.rtems.org/branches/master/eng/coding-formatting.html
So that one is manageable. The situation with spaces after parentheses
is trickier. There is a preference by some to avoid spaces in the
nested parentheses of arithmetic/logic expressions. This seems to be
somewhat consistent, but it is also a bit complicated to detect the
difference between:
z = ( x + y )
z = ( x + (x + y) )
Not impossible, but also not really standard anywhere that I have seen.
I would place spaces everywhere or nowhere around things involving ()[].
z = ( x + ( x + y ) )
or
z = (x + (x + y))
A main characteristic of the score style is the excessive use of spaces
around everything, but only two spaces for indentation ;-)
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
