New coding style for new files?

[Peter Dufault]

> On Sep 11, 2020, at 13:43 , Joel Sherrill <joel at rtems.org> wrote:
> 
> https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify
> 

I've been using "uncrustify" for a long time. There are regular updates and quick responses for clearly reported issues.

The formatting specification is complicated, but that goes along with being so configurable.  There are formatting specification GUIs and helpers that I haven't used to assist with the generation of the formatting spec. See the bottom of the main "github" page for "uncrustify".

Joel, when you were working with me the source code reformatting script we were using used "uncrustify" as the main reformatting engine.

I can not help with this much.  However, if I had time to do it, I think I'd do it this way:

- Choose files that the RTEMS community RTEMS agrees are perfect examples of RTEMS coding as reference sources.  There should be a few and some should be large.
- The "uncrustify" source includes sample configurations in its source code "/etc" directory.  Use a subset of the sample configurations to reformat the RTEMS reference sources.  For example, reformat to match FreeBSD, Linux kernel, K&R, etc coding styles and store them as test input files.
- Run "uncrustify" with a proposed RTEMS configuration file on the hacked reference files and then "diff" them with the original.

Ideally you would wind up with an RTEMS configuration with no diffs regardless of how you reformatted the input.

I know this would use the same tool that is being tested to create the input test files, but I think in this case it's OK due to how invasively "uncrustify" can be configured to reformat the code.  For example, it can probably strip "{" "}" on single lines in a conditional.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200911/9f013fde/attachment-0001.bin>