Add clang-format configuration

[MinyazevR]

Full description: #265

[mrbean-bremen]

Thanks, this looks good! I would like a couple of minor changes, and would like @usiems to have another look, before merging this.

[mrbean-bremen]

?

[usiems]

I would propose to use
AllowShortFunctionsOnASingleLine: Inline
here.

This way short inline functions in the header are put into one line.

[usiems]

'AfterCaseLabel: true' better matches the current style.

I rather dislike that the break behind a closing brace is put onto the same line, but found no option to influence this. The developers of clang-format seem to believe that this is as it should be.

[mrbean-bremen]

There is the option BreakBeforeBraces: Allman which would put all braces on a separate line, including the break. I would be fine with this, but it would be a larger change for the existing code base.

[usiems]

Nah, I don't like that, in my opinion this takes up too much space.

[usiems]

I would like this to be
AfterControlStatement: MultiLine
that is, put the brace on the next line if the if condition has more than one line.

[usiems]

Setting
AlignTrailingComments: true
neatly arranges the comments in the initialization lists of Python objects.

Speaking of initializer lists of Python objects: I noticed that clang-format collapses lines without trailing comments in these lists, which makes these less tidy. We should add trailing comments for these lines to keep the Python style (search for _HEAD_INIT in the code).

[usiems]

The value for this option is Never!

[mrbean-bremen]

Looks good from my perspective, thanks!
I leave it to @usiems to decide about the BreakBeforeBraces: Allman option.

[jamesobutler]

You may want to consider adding the clang-format hook to a pre-commit-config yaml as 3D Slicer and other related projects have adopted (see https://github.com/Slicer/Slicer/blob/1b1bbb22b4f858ff3d47d196de4ac491a0b9ea5c/.pre-commit-config.yaml#L27-L39). Pre-commit-config yml usage has been adopted by many projects and something that is generally called in a GitHub actions workflow file (e.g. lint.yml) using the pre-commit github action (https://github.com/pre-commit/action).

^This way new styling is applied consistently and enforced for every PR.

[mrbean-bremen]

Yes, good point! I'm using pre-commit in all Python projects, just didn't think about it here.

[mrbean-bremen]

@jamesobutler - pre-commit is added now, thanks for the suggestion!

[jamesobutler]

Great! Now just need a lint github workflow to run pre-commit where the workflow will fail if pre-commit detects issues.

[mrbean-bremen]

I had also enabled pre-commit.ci (as I do usually with pre-commit), so indeed the workflow will fail in this case.