Uncrustify

[Gedare Bloom]

On Wed, Oct 14, 2020 at 8:16 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Wed, Oct 14, 2020, 6:03 PM Chris Johns <chrisj at rtems.org> wrote:
>>
>> On 15/10/20 5:04 am, Joel Sherrill wrote:
>> > On Wed, Oct 14, 2020 at 12:11 PM Sebastian Huber
>> > <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
>> > wrote:
>> >     Hello,
>> >
>> >     I tried to write a configuration file for Uncrustify which is close to
>> >     the RTEMS coding style. This tool has really a lot of options. The
>> >     configuration file has more than 3000 lines. Apparently this is not
>> >     enough. I was not able to get function parameters properly aligned. For
>> >     example:
>> >
>> >     -  Thread_queue_Context  queue_context;
>> >     -  Thread_Control       *the_thread;
>> >     +  Thread_queue_Context queue_context;
>> >     +  Thread_Control      *the_thread;
>> >
>> >     It seems Uncrustify interprets the '*' as some sort of white space.
>> >     Attached is my current configuration file. You can test it for example
>> >     with cpukit/score/src/threadqenqueue.c.
>> >
>> > I'm not a huge fan of moving the * to after the type rather than against
>> > the name but if we accepted that change to the style, would the parameter
>> > names line up?
>>
>> I understand the history with multiple variable declarations per line but to me
>> the type with the modifier grouped together reads better. In C++ I prefer that
>> style because there are more type modifiers such as reference and the reference
>> and address-of is the same character. For example a randomly selected API ...
>>
>> https://en.cppreference.com/w/cpp/container/vector/vector
>>
>> ... and
>>
>>  vector& operator=( const vector& other );
>>
>> I had never noticed the C style until I used C++ heavily many years ago.
>
>
> I don't care as much about the placement as if this let's uncrustify align the parameter names.
>
> This is definitely in the category of something I'd comprise ob if the tool gives us an acceptable pattern overall.

I think this would be a positive change to readability for the reason
stated by Chris, in addition to probably easier to enforce.
>>
>>
>> Chris
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel