-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clang-format configuration #1920
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1920 +/- ##
==========================================
+ Coverage 86.80% 88.59% +1.80%
==========================================
Files 131 138 +7
Lines 3923 5619 +1696
==========================================
+ Hits 3405 4978 +1573
- Misses 518 641 +123 |
Right, I'll try to find some time to test the configuration out. However, since opening #1182, I started having some misgivings about clang-format. From my experience with other projects, it doesn't handle some constructs well, and the actual formatting depends on the specific version of clang-format, making inconsistencies likely. |
Please let me know if there are some issues. The result might not be perfect, but maybe we can get some consistency. |
So, I spent some time playing with the config and made some further changes (pushed them as a separate commit). There is still at least one problem that needs fixing before I am willing to say "use clang-format now". See below Some notes on the current settings
The big problem is with I think I will end up turning it on and trying it out a bit more, because I don't want to generate mostly pointless diff against all code. |
I've just check the clang docs, you are right, clang-format 10 doesn't mention it.
I see, in the worst case it might be an option to disable clang format for particular sections.
👍 |
Some notes on the configuration options chosen: * We want `AllowShortEnumsOnASingleLine` set to `false`, but that option is clang-format-11 and up, which is not out yet. * `IndentPPDirectives` is currently inconsistent, but `AfterHash` is the preferred style in new code. * `NamespaceIndentation` is a mess, but `All` is closer to the effect we want than `Inner`. * `SpacesInParentheses` set to `true` is not ideal due to it also introducing extra spaces in preprocessor expressions, but using it is much closer to the current style than not. All in all, using this setting globally would reformat pretty much every line of code in the codebase, but it is as close as possible to the bespoke style currently used. Still, it should only be used on the diffs. Closes catchorg#1182
Description
Initial
.clang-format
file, open for discussion. The config doesn't contain much as the defaults fit most cases already. Documentation of all options is available here.Settings to discuss / change
NamespaceIndentation
: Indention of namespaces –All
,Inner
orNone
?IndentPPDirectives
: Indention of proprocessor directivesGitHub Issues
#1182