Tabs in Source Files [C, H]

[Sebastian Huber]

----- Am 7. Aug 2019 um 17:43 schrieb Gedare Bloom gedare at rtems.org:

> On Wed, Aug 7, 2019 at 8:31 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> ----- Am 7. Aug 2019 um 16:24 schrieb joel joel at rtems.org:
>>
>> > On Wed, Aug 7, 2019 at 8:59 AM Sebastian Huber <
>> > sebastian.huber at embedded-brains.de> wrote:
>> >
>> >> ----- Am 7. Aug 2019 um 15:41 schrieb joel joel at rtems.org:
>> >>
>> >> > Hi
>> >> >
>> >> > While looking at assembly language formatting, I decided to grep for tabs
>> >> > in source
>> >> > files. In cpukit and testsuites, there are a LOT of files with tabs.
>> >> >
>> >> > $ find cpukit testsuites/ -name "*.[ch]" | xargs -e grep -rlP "\t" | grep
>> >> > -v libnetworking | grep -v pppd | grep -v contrib | wc -l
>> >> > 530
>> >> >
>> >> > That may be picking up a few extra files but that's still a lot of files.
>> >> >
>> >> > Any comments?
>> >>
>> >> My approach to white space in source files would be to pick up the best
>> >> source code formatter available, select a configuration which fits best to
>> >> the existing style, run it over the code (excluding code which we want to
>> >> keep in synchronization with an upstream) and later run every commit
>> >> through it.
>> >>
>> >
>> > I'm not disagreeing with you but no one has ever found a formatter and
>> > defined a style that matches.
>>
>> Yes, we invested some time to evaluate clang-format early this year and failed
>> to produce useful results. They even rejected to accept potential contributions
>> to support this style because it seemed to be to exotic. I don't have a
>> problems with the RTEMS style. But I think in the long run a style supported by
>> a good formatter which is ubiquitously used (e.g. Linux, BSD, Google, GNU)
>> would be beneficial. If you use an ubiquitous style, you make it easier for new
>> contributors.
>> _______________________________________________
> Considering our relationship with the BSDs, adopting that style might
> make the most sense if we decide to go that route.

Yes, but the key issue is the availability of a bullet proof automatic formatter.

> 
> It will cause a lot of churn in the repo though, some care must be taken.

It is just something to think about, I don't propose anything. When I look back most of the review comments are about white space. This is just a waste of developer time. For my contributions to the Doorstop project written in Python reading a style guide was unnecessary. When you run the tests, your code is automatically formatted for you.

With an automatic formatter, we could also think about a modernization of our C style, e.g. declare and initialize variables as close as possible to their first use:

https://google.github.io/styleguide/cppguide.html#Local_Variables

This includes for (int i = 0; ...