gedare at rtems.org
Thu Oct 15 15:16:48 UTC 2020
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 ...
>> ... 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.
> devel mailing list
> devel at rtems.org
More information about the devel