Uncrustify

[Joel Sherrill]

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.

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201014/f3ae48ea/attachment.html>