New coding style for new files?

[Joel Sherrill]

On Fri, Sep 11, 2020 at 1:11 PM Peter Dufault <dufault at hda.com> wrote:

>
>
> > 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 didn't know since it was hidden. :)

>
> 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.
>

This is a decent plan. There are at least 12 files over 400 lines in the
cpukit (score, rtems, sapi, and libcsupport) that I would consider
potential candidates for this.

This matches my idea of minimizing the delta between defined current style
and what the tool supports. Then we can decide to bend to the tool or push
for changes to the tool.


> 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.
>

I like dense code and will admit it. I don't like styles that spread braces
onto separate lines so you end up with this:

if ()
{
...
}
else
{
}

But I have come to appreciate that single like if's with no braces can be
viewed as issues in safety and security coding standards so I am willing to
give that up and a tool will help fix those with low effort if we get a
good match on the other rules.

FWIW I have also come to believe that anything other than a single logical
test in a logical expression should be eliminated or at least avoided. I
just came off a project where doing that gave us very high Statement
Coverage and produced no cases where MC/DC coverage analysis had to be
done. A tool can't rework compound logical expressions into a series of
simple ones, but we may want to consider a style that discourages any
logical expression that would require MC/DC analysis. This appears to be a
decent discussion of the topics:

https://people.eecs.ku.edu/~hossein/Teaching/Fa09/814/Lectures/structural-testing-mcdc-tut.pdf

Thanks Peter. This does appear to be the approach to narrowing down the
settings and getting to where we can trust them.

--joel


>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200911/e717b63c/attachment.html>