style patches - discuss

[Joel Sherrill]

On Thu, Jul 27, 2023, 1:13 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>
>
> 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
>
> >


I would prefer the space not be there.

>
> > 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 ;-)
>

There is a reason for that. No tabs and staying under 80 columns. Two
spaces is visually enough without wasting indentation.

No change.

>
> --
> 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/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230727/725d37f8/attachment.htm>