As this is new to our project I expect that we’ll need a bit of time to adjust to it, and probably fine tune the format file, the documentation as well as the CI integration.
We will not reformat the whole tree as we don’t want to mess up the git history. For that reason the changes and process are focused on dealing only with change sets for now.
Defining the clang-format file and creating the CI integration has been done by Roland Fischer:
There was a short discussion on one of the pull request to which I added this. We should add it in here as well.
Thanks Victor. As you’ll see in the doc, there are different ways to reformat changes. I’d recommend to reformat before committing, but you can also reformat your whole branch after the fact.
As recently found out, there’s a caveat with enum reformatting. Unfortunately, clang-format will reformat the whole enum and not just what has changed for enums. This is a feature/bug of clang-format.
Hence, my proposal would be to commit the enum change without reformatting. Then reformat the last commit (see doc) and commit the formatting separately. This way you’ve got the formatting change from the actual change which is always good to have for bigger formatting.
Most of them support “format selected code” and “format whole file” features out-of-the-box. This can be convenient/helpful for new code or where the whole file/section already is correctly formatted.
However, as Victor said, please pay attention to only format your changes for existing code.
You can configure most IDE and editors to run external commands upon some keystroke. You could configure them to run the helper script to only change the currently changed code as described in doc / devguide / code style / Formatting code in staging:
If you also want to change the unstaged changes, do:
$ git clang-format --force
# Or with script:
$ scripts/clang-format.sh cached --force
Or run that from your command line to reformat changes in staging as well as unstaged changes, i.e. things you are currently editing.