Message ID | 20240723082111.874382-2-karthik.188@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | e3ea432528dc5bfcdff89c1b6afeaa6d423fd4ee |
Headers | show |
Series | clang-format: add more rules and enable on CI | expand |
On Tue, Jul 23, 2024 at 10:21:06AM +0200, Karthik Nayak wrote: > We do not have a rule around the indentation of preprocessor directives. > This was also discussed on the list [1], noting how there is often > inconsistency in the styling. While there was discussion, there was no > conclusion around what is the preferred style here. One style being > indenting after the hash: > > #if FOO > # if BAR > # include <foo> > # endif > #endif > > The other being before the hash: > > #if FOO > #if BAR > #include <foo> > #endif > #endif > > Let's pick the former and add 'IndentPPDirectives: AfterHash' value to > our '.clang-format'. There is no clear reason to pick one over the > other, but it would definitely be nicer to be consistent. > > [1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g > > Signed-off-by: Karthik Nayak <karthik.188@gmail.com> This doesn't necessarily have to be part of this patch series, but I think that we should document this as part of our CodingGuidelines, as well. I planned to send an update to the coding guidelines soon anyway, so I can handle that once this topic lands. Patrick
Patrick Steinhardt <ps@pks.im> writes: > On Tue, Jul 23, 2024 at 10:21:06AM +0200, Karthik Nayak wrote: >> We do not have a rule around the indentation of preprocessor directives. >> This was also discussed on the list [1], noting how there is often >> inconsistency in the styling. While there was discussion, there was no >> conclusion around what is the preferred style here. One style being >> indenting after the hash: >> >> #if FOO >> # if BAR >> # include <foo> >> # endif >> #endif >> >> The other being before the hash: >> >> #if FOO >> #if BAR >> #include <foo> >> #endif >> #endif >> >> Let's pick the former and add 'IndentPPDirectives: AfterHash' value to >> our '.clang-format'. There is no clear reason to pick one over the >> other, but it would definitely be nicer to be consistent. >> >> [1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g >> >> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> > > This doesn't necessarily have to be part of this patch series, but I > think that we should document this as part of our CodingGuidelines, as > well. I planned to send an update to the coding guidelines soon anyway, > so I can handle that once this topic lands. > > Patrick Yeah, that would be great indeed. I think this series is now merged to next. Thank Patrick
diff --git a/.clang-format b/.clang-format index 3ed4fac753..5e128519bf 100644 --- a/.clang-format +++ b/.clang-format @@ -96,6 +96,12 @@ BreakStringLiterals: false # Switch statement body is always indented one level more than case labels. IndentCaseLabels: false +# Indents directives before the hash. +# #if FOO +# # include <foo> +# #endif +IndentPPDirectives: AfterHash + # Don't indent a function definition or declaration if it is wrapped after the # type IndentWrappedFunctionNames: false
We do not have a rule around the indentation of preprocessor directives. This was also discussed on the list [1], noting how there is often inconsistency in the styling. While there was discussion, there was no conclusion around what is the preferred style here. One style being indenting after the hash: #if FOO # if BAR # include <foo> # endif #endif The other being before the hash: #if FOO #if BAR #include <foo> #endif #endif Let's pick the former and add 'IndentPPDirectives: AfterHash' value to our '.clang-format'. There is no clear reason to pick one over the other, but it would definitely be nicer to be consistent. [1]: https://lore.kernel.org/r/xmqqwmmm1bw6.fsf@gitster.g Signed-off-by: Karthik Nayak <karthik.188@gmail.com> --- .clang-format | 6 ++++++ 1 file changed, 6 insertions(+)