What clang-format config should we adopt?

At today sync we started discussing about how we can choose a clang-format config to be used in all Beman repos. I moved the discussion here.

Possible options:

  1. Use a default config - e.g. LLVM (https://clang.llvm.org/docs/ClangFormatStyleOptions.html).
  2. Use a custom / hand-made config.

My summary:

  • A default config is easier to use, but it may restrict some features/rules (e.g., style LLVM enables rules that were accepted in the LLVM project). We want to be able use linter for cutting edge C++ features (e.g., reflection).
  • A custom config is harder to maintain, but more stable.

Beman repos current status: none repo has a stable/portable clang-format config (the one from optional26/execution26 was probably made by hand and not testing on multiple clang-format versions).

3 Likes

Option 2 may be simplified by the result of this thread: Should we have a dedicated repo for infrastructure?

My vote would be for option 2 but to centralize it in a dedicated repo. I think this will provide us with the greatest control over the style and will hopefully allow us to keep formatting consistent even when using new language features.

1 Like

How would other projects make use of that .clang-format? My understanding is that the .clang-format needs to live in one of the parent directories of the source code file.

Maybe the “master” .clang-format lives in beman/exemplar and other projects can pick it up as desired?

There is also discussion on this topic in Define `.clang-format` or equivalent · Issue #29 · beman-project/exemplar · GitHub

1 Like

What if we take Carbon’s lead and decide on an official Beman Style Czar who gets ownership of beman.exemplar’s .clang-format and other automated style configurations? If we do this, the time we spend on formatting concerns gets minimized.

A good person for this would be someone who cares about this kind of thing. I’m thinking @Sdowney since he cared enough to make a custom style for beman.optional26. Thoughts?

1 Like

They could pull in the infrastructure repo as a submodule and then can use clang-format --style=file:<path to file>. This can put in a script or made a CMake build target to run clang-format over all the files in the project.

You are right, though, that this will break the case where devs format files inside their editor or their editor is configured to format on save.

I like this idea. I’m happy to conform to whatever style as long as the tooling does it for me :slight_smile:

I would just request we do away with whatever this is:

(This is: AlignConsecutiveAssignments).

As caught by: Introduce basic linting infrastructure by wusatosi · Pull Request #34 · beman-project/exemplar · GitHub

Check out the this commit, I applied the clang-format file from optional library, and all the c++ related reformat change is in there.

[@river Just imagine how much better that formatting would look if the code said auto const. :wink: ]

Jokes aside, what are you looking for? to establish a recommended clang-format specification? If so, I can contribute this one to the project boost-multi/.clang-format at master · correaa/boost-multi · GitHub

I am sure there are more serious users of clang-format here (more serious than me); but the main value it has is that it was 0) carefully crafted for many years, 1) specifically for a header-library and its tests, 2) it pleases all clang-tidy formatting requests, 3) it pleases cppcheck and cpplint if you care about these, 4) looks good :wink:

(disclaimer: it uses tabs for indentation and spaces for alignment, but that can be changed with one option)