| Message ID | 64e0b449936a6828ead98438d621f7e7684546c8.1721818488.git.ps@pks.im (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Documentation: some coding guideline updates | expand |
Patrick Steinhardt <ps@pks.im> writes: > There has recently been some discussion around how C preprocessor > directives shall be indented [1]. This discussion was settled towards > indenting after the hash by two spaces [2]. Document it as such. It was settled to have space after and not before the hash, but I do not recall ever agreeing to two spaces. I prefer to increment by 1 for each level instead to keep the whole thing less distracting while carrying meaningful information. Thanks.
Junio C Hamano <gitster@pobox.com> writes: > Patrick Steinhardt <ps@pks.im> writes: > >> There has recently been some discussion around how C preprocessor >> directives shall be indented [1]. This discussion was settled towards >> indenting after the hash by two spaces [2]. Document it as such. > > It was settled to have space after and not before the hash, but I do > not recall ever agreeing to two spaces. I prefer to increment by 1 > for each level instead to keep the whole thing less distracting > while carrying meaningful information. Using the indentation consistently is a good thing I do not object to. Among our existing header and source files (excluding compat/ that is full of borrowed sources), scanning output from $ git grep -e '# *' '*.[ch]' ':!compat/' tells me that - builtin/gc.c (3 lines) - git-compat-util.h (52 lines) - trace.c (2 lines) - wildmatch.c (6 lines) use one space indent after '#' per level, while - hash.h (10 lines, inconsistently 2 uses 1 per level) - thread-utils.c (8 lines) use two space indent after '#' per level. In compat/ directory, only compat/nedmalloc uses 2-space indent. There in the hierarchy are so many files we borrowed from GNU, whose coding style sticks to one-space indent.
On Wed, Jul 24, 2024 at 10:06:03PM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Patrick Steinhardt <ps@pks.im> writes: > > > >> There has recently been some discussion around how C preprocessor > >> directives shall be indented [1]. This discussion was settled towards > >> indenting after the hash by two spaces [2]. Document it as such. > > > > It was settled to have space after and not before the hash, but I do > > not recall ever agreeing to two spaces. I prefer to increment by 1 > > for each level instead to keep the whole thing less distracting > > while carrying meaningful information. > > Using the indentation consistently is a good thing I do not object > to. > > Among our existing header and source files (excluding compat/ that > is full of borrowed sources), scanning output from > > $ git grep -e '# *' '*.[ch]' ':!compat/' > > tells me that > > - builtin/gc.c (3 lines) > - git-compat-util.h (52 lines) > - trace.c (2 lines) > - wildmatch.c (6 lines) > > use one space indent after '#' per level, while > > - hash.h (10 lines, inconsistently 2 uses 1 per level) > - thread-utils.c (8 lines) > > use two space indent after '#' per level. > > In compat/ directory, only compat/nedmalloc uses 2-space indent. > There in the hierarchy are so many files we borrowed from GNU, whose > coding style sticks to one-space indent. Thanks for checking. I don't really mind whether we use one or two spaces, as long as we are being consistent. I actually took the 2-space indent from the comment for "IndentPPDirectives" in ".clang-format", where it looks as if clang-format was using two spaces. So I took this as being the official style we settled on. One thing I noticed though is that clang-format is inconsistent with either of those styles because it uses a tab character to indent nested preprocessor directives. So the comment we have in that file is quite misleading. We can fix this with the below change though. I'll add that to this series. Patrick diff --git a/.clang-format b/.clang-format index 16fd12253e..0e3606a8bb 100644 --- a/.clang-format +++ b/.clang-format @@ -105,6 +105,7 @@ IndentCaseLabels: false # # include <foo> # #endif IndentPPDirectives: AfterHash +PPIndentWidth: 1 # Don't indent a function definition or declaration if it is wrapped after the # type
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 1d92b2da03..1d09384f28 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -214,6 +214,16 @@ For C programs: - We use tabs to indent, and interpret tabs as taking up to 8 spaces. + - Nested C preprocessor directives are indented after the hash by two + spaces per nesting level. + + #if FOO + # include <foo.h> + # if BAR + # include <bar.h> + # endif + #endif + - We try to keep to at most 80 characters per line. - As a Git developer we assume you have a reasonably modern compiler
There has recently been some discussion around how C preprocessor directives shall be indented [1]. This discussion was settled towards indenting after the hash by two spaces [2]. Document it as such. [1]: https://lore.kernel.org/all/xmqqwmmm1bw6.fsf@gitster.g/ [2]: https://lore.kernel.org/all/20240708092317.267915-2-karthik.188@gmail.com/ Signed-off-by: Patrick Steinhardt <ps@pks.im> --- Documentation/CodingGuidelines | 10 ++++++++++ 1 file changed, 10 insertions(+)