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