Prototype clang-format based code-formatting tool

[willend]

Free-form text area

Please describe what your PR is adding in terms of features or bugfixes:

After discussions with @Lomholy here is a prototype python-tool (in devel/bin/mccode-clangformat). The tool implements “standardised indentation style” for components based on this set of clang-format settings:

BasedOnStyle: GNU
IndentWidth: 2
UseTab: Never
BreakBeforeBraces: Attach
ColumnLimit: 160
DerivePointerAlignment: false
PointerAlignment: Left
IndentPPDirectives: BeforeHash

(And further in the python-layer indents % and # lines inside %{…%} blocks.)

Short term plans are to

• Use the tool on all comps in the repo, one category at a time
• Add a TODO item / reminder in the PR-template to use this tool when contributing / changing components
• Integrate a check (in the basictests) to ensure the tool has been used on modified comp code
• Add conda dependency clang-format in devel/bin/ mccode-create-conda-yml

Potential later improvements:

• Similar scheme should be added to any share files (manually?) and later potentially integrated in CI?
• Look at using this for instr files also
• Eventually we should even think of using this to adapt the cogen to produce “nicer output”...
• The long ColumnLimit of 160 is only present since there are very long in-line comments in critical places in the codebase. This should be handled manually in a case-by-case process later, after which we should be able to reduce the limit.

For input / comments / reflections please add to the discussion @mads-bertelsen @farhi @g5t @tkittel @ebknudsen ?

---

PR Checklist for contributing to McStas/McXtrace

• My contribution contains something else

  • Explanation is added in free form text above or below the checklist

---

[willend]

FYI I have applied the tool to most of the McStas comp categories on a set of separate branches, test output seems fine:

• monitors
• sasmodels
• union
• optics
• misc
• contrib

[tkittel]

+1 for this. Even if there will be some pains in the beginning, I am sure that it will be super nice to have in the long run.

We might consider expanding this kind of automated monitoring of quality and consistency. For instance:

• Enable warnings during compilation (would be even more useful than style linting IMHO).
• Expand the linting to non-C parts of the code (i.e. that the component comments on top are in line with best practices for mcdoc...).

Anyway, back on topic I have noticed that the OpenMC developers have a specific clang-format version pinned in the CI where it is used. Presumably this was caused by inconsistencies between different versions of clang-format. Just something to be aware of. For the beginning, we can probably just put a lower version number pinning on clang-format and hope that there won't be too many inconsistencies going forward (and that we can simply update the pinning and update a few components if there are).