Indenting for nested preprocessor directives

[Peter Kasting]

I propose that we set clang-format's `IndentPPDirectives` value to `AfterHash` (documentation: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#indentppdirectives).

The effect will be to change nested preprocessor directive indenting from our current "no indent" style:

#if FOO

#if BAR

  void DoStuff();

#endif

#endif

To a style that adds after-hash indenting:

#if FOO

#  if BAR

  void DoStuff();

#  endif

#endif

This is compliant with the Google Style Guide, which allows both the above styles (see https://google.github.io/styleguide/cppguide.html#Preprocessor_Directives).

I do not propose doing a mass reformat for this.  If we do it, it might be worth an explanatory note to chromium-dev@ since people will notice it.

Rationale: I believe the above improves readability and reduces the need for trailing comments after #endifs, which can be very confusing in the presence of #else (because it's not clear if the trailing comment should state the "original" or "negated" condition). I do not propose we add any style guidance discouraging such trailing comments; I just don't want to have as much reason to consider doing so :)

PK

[Nico Weber]

I think we don't want to change the clang-format settings file frequently.

And making deeply nested ifdefs look nice kind of sets the wrong incentive :)

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAO5B8RtRSeuW4yDbuSHy0gbp3htb1Te-%2BfxfaJXOvprNNqhrwQ%40mail.gmail.com.

[K. Moon]

I've used this style in the past, and the mismatch in the indents between the wrapped code and the preprocessor directives can get kinda confusing.

I do think avoiding a lot of nested #if is generally better, although if you have to have a lot of nesting for some reason, I like the indented style a bit more, personally. A lot of folks aren't familiar with it, though, so maybe a small readability speed bump there.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADZ1XiY427iPW-b1CH%2BAWL3hZCdrvhvaTie5FV%3D1g%3DNs9tjqnw%40mail.gmail.com.

[Peter Kasting]

On Thursday, August 28, 2025 at 10:35:25 AM UTC-7 km...@chromium.org wrote:

I've used this style in the past, and the mismatch in the indents between the wrapped code and the preprocessor directives can get kinda confusing.

I do think avoiding a lot of nested #if is generally better, although if you have to have a lot of nesting for some reason, I like the indented style a bit more, personally. A lot of folks aren't familiar with it, though, so maybe a small readability speed bump there.

Are you saying you think this would be a net win with caveats, or more just mixed results depending on the situation and reader (in which case we shouldn't make the change)?

PK

[Peter Kasting]

On Thursday, August 28, 2025 at 10:19:17 AM UTC-7 Nico Weber wrote:

I think we don't want to change the clang-format settings file frequently.

Have we changed it recently? The last substantive change I'm aware of was pbos' braces change, which is ~2 years ago at this point.

We could certainly rate-limit substantive changes to whatever we want. Given that we're not doing mass reformats I don't know that it matters much. Seems like the more interesting question is simply whether a formatting change is a win or not.

And making deeply nested ifdefs look nice kind of sets the wrong incentive :)

No disagreement with both you  and Kahmy that if possible, avoiding nested #ifs is best.

If (for the sake of argument) this does make them slightly more readable, though, I am skeptical people will actually use them meaningfully more. If someone is using nested #ifs, I suspect either they actually need to (so this would be a win), or else they're not someone deterred by the inherent ugliness of nested #ifs (in which case they were gonna do it anyway, and hopefully their reviewer will suggest a better alternative).

PK

[K. Moon]

Like Nico, I'm leery of the incentives. I'm less sanguine that making a pattern less terrible won't encourage it being used much more than desired.

On the balance, I think the conservative option is to leave things ugly and encourage folks to reduce use of nested conditionals in general.

All things being equal, I think indenting would be an improvement vs. not, at a given snapshot of the code base, but I don't think all things are equal here.

[Gabriel Charette]

If we temporarily ifdef out some code, it'd get indented and affect history (blame). Is that good? In a way, the affected code did change (stopped vs resumed running, on some platforms) but it also didn't (logic wise)...

I also worry about the wasted horizontal space, we don't nest code in namespaces, this feels similar?

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACwGi-4OGfZ2wdaAG39pvZz8WxkY47yWiZYYOw%2BvUkoouxSSOA%40mail.gmail.com.

[Peter Kasting]

On Thu, Aug 28, 2025 at 2:31 PM Gabriel Charette <g...@chromium.org> wrote:

If we temporarily ifdef out some code, it'd get indented and affect history (blame). Is that good? In a way, the affected code did change (stopped vs resumed running, on some platforms) but it also didn't (logic wise)...

I also worry about the wasted horizontal space, we don't nest code in namespaces, this feels similar?

To be clear, this ONLY affects the directives themselves, not the code contained in them.

PK

[Gabriel Charette]

Oh! Interesting, I could see how this helps understand when a directive is under the scope of another one. I don't see how this helps comments on #else though?

 

PK

[Peter Kasting]

My hope was that trailing "end of directive" type comments were most appealing to people with nested directives, to distinguish which thing was being "else"d/ended. And if this made that sufficiently clear, people would have less reason to add those comments.

However, given the lukewarm response thus far, unless a bunch of people speak up in favor of this it doesn't look like it will get consensus.

PK

[Roland McGrath]

I heartily endorse indented directives (whether spaces-after-# or spaces-before-#, both of which have been valid for decades).  I think everybody should always have been using them everywhere, regardless of trailing comment conventions or how much or how little directive nests can be avoided.  But I'm not an active contributor whose speaking up counts.

[Giovanni Ortuño]

I also support indented directives. There are places where we have to use directives and this change would help readability. Example

On Fri, Aug 29, 2025 at 9:32 PM Roland McGrath <mcgr...@chromium.org> wrote:

I heartily endorse indented directives (whether spaces-after-# or spaces-before-#, both of which have been valid for decades).  I think everybody should always have been using them everywhere, regardless of trailing comment conventions or how much or how little directive nests can be avoided.  But I'm not an active contributor whose speaking up counts.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAB%3D4xhpToVt0Pxd%2BVBbnm-9wVaPj7hvGXvXNoo4xoxsC%2Bb1%2B-Q%40mail.gmail.com.

[Jeremy Roman]

I tend to think that having them not be indented makes it clearer that this is a concept that is outside the normal scoping rules of C++, and even this example isn't very compelling to me (it's not that bad, and we could refactor it in other ways to avoid the nesting).

On the other hand, things like conditionally compiling a test based on platform are quite common and having extra indentation for that (and blame diffs when it changes) would be unfortunate.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMDKGBVGKeFNGX_fL3JpC_wSxuW%3D7Lpbpg9%3DOc0BuiVvbj9v9Q%40mail.gmail.com.

[Peter Kasting]

My summary of this thread is that while the majority of responses believe readability is slightly improved, support is not strong, and multiple people have concerns about other effects (e.g. perverse incentives).

If someone strongly wants this, my suggestion is to find a couple files with a lot of nested directives and reformat them with this setting -- both one that seems "as compelling as possible" and one that seems "as cautionary as possible". Perhaps views will change on seeing non-toy examples.

I do not have sufficient time and passion to drive that, so I will consider this conversation "closed no consensus" unless someone else does the above.

Thanks all,

PK

[K. Moon]

Thanks, Peter! Appreciate you bringing this up, as well as bringing it to a conclusion.

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAO5B8RuYXJC4Xv_wdH%3D9WnvjDZsWJP8HhvYsrLeEt0DvVVb3gg%40mail.gmail.com.

[Nico Weber]

Another point is that we try to follow Google style unless there's a great reason not to. So if someone were to push for this, they should push changing Google style in upstream clang-format, then we'd pick it up automatically from there.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACwGi-7DHiANpB1x-A%2BwTC%2B3tSS9nb2Rie2jRsd073oBt0J4RQ%40mail.gmail.com.

[K. Moon]

I have a different take on that point: As mentioned earlier in this thread, the indented style is already permissible in the published C++ guide (although the "#" must start in the first column):

https://google.github.io/styleguide/cppguide.html#Preprocessor_Directives

So it's style-compliant to indent (after the "#"), but clang-format would need to be reconfigured. I don't think that change rises to the same level of needing to push through a change to the upstream default for Google style.

I think the procedure Peter outlined (if someone wants to push this forward, come up with a comparison of compelling examples and counter-examples) would be satisfactory.

[Nico Weber]

"Follow Google style" in the `clang-format -style Google` sense.

[Peter Kasting]

But we don't do that. We use style=chromium. I disagree that we are beholden to the clang-format style=google defaults in the same way we are beholden to "follow Google style unless there is a good reason not to" (which, as noted, this complies with).

I don't disagree that, if this were a good default for Chrome's formatting settings, it would at least arguably be a good default for Google also; and so, in theory, it might be nice to do what you suggest. However, I don't think we should set a precedent of this level of stop energy by saying that it is required. We didn't do that with inserting braces on conditionals either (rightfully, IMO, despite that I disagreed with the change).

PK