On Wed, Oct 14, 2020 at 8:16 PM Joel Sherrill <j...@rtems.org> wrote: > > > > On Wed, Oct 14, 2020, 6:03 PM Chris Johns <chr...@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.hu...@embedded-brains.de >> > <mailto:sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
