[clang] [clang-format] Add KwBreakBeforeCaseLabel (PR #227668)

Anan Yablonko via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 30 15:07:56 PDT 2026


ananski-the-3rd wrote:

@HazardyKnusperkeks
Thank you for your reply.

Let me respond to the technical side first:

### Naming
It is challenging that options use the "BreakBeforeX" convention with "Break" meaning a "newline" where in my case a "Break" is a literal `break` keyword.

To escape this conflict, I'd suggest:
- `AllowKeywordsBreakAndCaseOnASingleLine` (uses convention but a bit wordy)
- `CompactCaseLabels` (concise but has only `CompactNamespaces` as precedent)

### The extra pass
The KwBreakInserter only exists to insert the first, aesthetic `break` before the first `case`:

```c
switch (n) {
  /*here*/ case 0:
    foo();
  break; default:
    bar();
}
```

Adding it is nice for migrating from the "classic" format but not strictly necessary. I accept that this can be removed completely to reduce maintenance burden.

### Tests and sorting
will be updated to match changes to the above.

---

As for the argument in favor of this option:
Admittedly, there are not many examples of this format being used or advocated for.
[Mr. Herb Sutter's cppfront](https://github.com/hsutter/cppfront) does not have a style guide that I could find, but it does use a version of this formatting and has dozens of contributors.

I'll argue therefore on the intrinsic merits of this format rather than on its reputation:
- A fallthrough-case in this style stands out since it has a shorter `case x:` line. This is much more prominent than the "classic" style.
- The `break` doesn't take its own line. Makes the actual logic stand out more.
In other words - the scaffolding of `break; case`, compared to the "classic" `break;\ncase`, is easier to ignore when consistent, **and** catches the eye when inconsistent. I believe this improvement to conciseness and readability at once is the mark of a good format style.

I agree to remove the additional pass and to make use of CanBreakBefore where appropriate.

Greetings,
Anan


https://github.com/llvm/llvm-project/pull/227668


More information about the cfe-commits mailing list