style patches - discuss

[Sebastian Huber]

On 26.07.23 17:17, Gedare Bloom wrote:
> On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
> <sebastian.huber at 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.huber at 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/