Add a formatting style and apply it to the entire repo

[TimSiebert1]

This PR adds

• a .clang-format file
• a clang-format worfklow for checking the formatting style of a PR or push

Based on the .clang-format style, the entire repo is formatted. This will potentially cause many errors that will be fixed here.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ TimSiebert1
❌ Clang Robot

---

Clang Robot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[TimSiebert1]

@awalther1 is the license check required? I used a bot to format everything. The bot can not sign the license :D

[awalther1]

I think that in this case it is OK to proceed without the signed licence ;-)

[cgraeser]

When checking which style is used to update my PR I noticed that you're running clang-format on ubuntu-latest for the workflow. AFAIK different versions of clang-format do not necessarily produce consistent results for the same settings. We stumbled upon this elsewhere (but with uncrustify). To avoid such issues it may be helpful to fix the version for the underlying distribution.

[TimSiebert1]

When checking which style is used to update my PR I noticed that you're running clang-format on ubuntu-latest for the workflow. AFAIK different versions of clang-format do not necessarily produce consistent results for the same settings. We stumbled upon this elsewhere (but with uncrustify). To avoid such issues it may be helpful to fix the version for the underlying distribution.

Thanks for the hint!
The current workflow was simply to apply the format and wait to see what happens. The current workflow tries to format and will not give you any warning or error if you didnt follow the style. Once I have fixed the format, I will change the workflow such that it errors when the style is not applied and the os will be fixed too.

[TimSiebert1]

@cgraeser I decided to go with the latest ubuntu and clang-format versions in the action, since I would expect a higher chance that the most recent version of clang-format handles the format equally for different OS. On the other hand on systems like MacOS only a limited amount of older versions are available on brew. If we have constant trouble with the formatter because the latest clang-format version on various machines creates a different format or the github action errors because it utilizes a different version, I would create a git hook based on nixos. This would allow us to ultimately fix the os and version for the github runner and between every contributor of the package.

I also dont want to add a bot that automatically commits the formatted files when there are formatting issues for a PR, because of the acceptance with the license.

[cgraeser]

My main worry was not about the version being too new. I just wanted to hint at the fact that the precise definition of ubuntu-latest and the incorporated clang-format version may change in a few months. Thus e.g. using ubuntu-24.10 would be more robust and precise.

[TimSiebert1]

Hi @cgraeser

what I meant above was that the robustness of the github action alone is not that helpful since every contributor would need the version that is given by the fixed ubuntu version. I would expect that this is not possible for different OS or at least it is not that easy. To gain a bit of robustness, I would assume that the newest version of clang-format for the latest OS is easier to obtain. However, if we have constant issues with it, I will change it.

[TimSiebert1]

What do you think about dumping the llvm style into the .clang-format to precisely fix the style? That should make the formatting a bit more robust.

[TimSiebert1]

EDIT: To make the workflow more robust (as proposed by @cgraeser)

• I fixed the clang-format version to 19.1.3, which is available on pip
• the llvm style is bumped to .clang-format