On Thu, Jul 27, 2023, 1:13 AM Sebastian Huber < sebastian.hu...@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.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 > > > 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.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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel