-
-
Notifications
You must be signed in to change notification settings - Fork 236
builtins.cpp: #ifdef OS_NT ... #else ... #endif part: more human-readable.#69
Conversation
@grafikrobot
grafikrobot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like indenting for scope, even the preprocessor logic. Unfortunately this style of indent means that, in the future, when/if we use something like clang-format it will reformat to put the # back at column 0. Hence I would prefer if the indent padding is after the #. Like this:
#if X
# if Y
# endif
#endif
Which is what the previous code has. It's just that it's been a really small indent, as opposed to the current preference of indenting on 4. Otherwise, the change looks fine.
DoctorNoobingstoneIPresume
commented
Aug 7, 2021
Thank you for answer ! (-:
I do like indenting for scope, even the preprocessor logic. Unfortunately this style of indent means that, in the future, when/if we use something like clang-format it will reformat to put the
#back at column 0.
In https://stackoverflow.com/questions/24476165/indenting-preprocessor-directives-with-clang-format , could you please see the 2021年02月02日 answer by Gabriel Staples ?
Than answer has directed me here: https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html -- where I can "Find in page" (Ctrl+F) "BeforeHash":
PPDIS_BeforeHash (in configuration: BeforeHash) Indents directives before the hash.
#if FOO
#if BAR
#include <foo>
#endif
#endif
IMO:
- the spacing before the
#enhances readability a lot; - the four-spaces-versus-one-space after the
#enhances readability only a little bit.
But I think this is highly subjective matter. :)
Hence I would prefer if the indent padding is after the
#. Like this:#if X # if Y # endif #endifWhich is what the previous code has. It's just that it's been a really small indent, as opposed to the current preference of indenting on 4. Otherwise, the change looks fine.
FWMOIW (For Whatever My Opinion Is Worth), if the only difference is four-spaces-versus-one-space, then perhaps we leave it with one-space => the output of git diff, git log -p etc. is not affected... :'(
If this looks good, we can do the same for the following part:
=>