[PATCH] D43183: clang-format: introduce `CaseBlockIndent` to control indent in switch

Daniel Jasper via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 13 06:36:57 PST 2018


djasper added a comment.

In https://reviews.llvm.org/D43183#1006170, @Typz wrote:

> > We'll just format those cases in a somewhat weird way and users can either accept that or change their code to not need it.
>
> I think we have a really diverging opinion on this. From my experience, people will mostly accept the output of the formatter without question : therefore I think we should strive to have the formatter format things as "correctly" as possible. And looking at the existing options and various complex formatting algorithms implemented I think this reasoning has been applied to some extent :-)
>  So I personnally would be willing to add some code/options even for such kind of corner cases; but then I am not the one maintaining the clang-format project.


I have no problem with making clang-format format things "correctly" and I am happy to add code. But I think we are doing the average clang-format user a disservice if we provide options for every such corner case. Let's settle on one good-enough behavior and go with that for everything/everyone.

>> I don't particularly care which of these options we go with, but I would be really hesitant to introduce an style flag for it. This is so rare, that almost no one needs this flag (or should need this flag). Thus, the cost of the flag (discoverability of flags for users, increased maintenance cost, etc.) strongly outweigh the benefit.
> 
> Any change will still require a new flag somewhere, since the currently implemented behavior is :
>  1- the documented way to format in Google style
>  2- the expected format in LLVM style, according to the clang-format unit test
> 
> It should thus probably not be changed.

I don't think that's true for the alternative I am suggesting.

>> IMO, for the same reason, this specific issue will not become part of the style guide of projects.
> 
> I definitely agree on this, but it is actually part of some styles (e.g. Google's)
> 
>> If you want to change something, I'd vote for making clang fall back to this behavior:
>> 
>>   case A:
>>     {
>>       stuff();
>>     }
>>     moreStuff();
>>     break;
>>   }
>>    
>> 
>> i.e. not let it put the "{" on the same line as the "case ..." if there is a trailing statement (other than "break;" maybe).
> 
> I am fine with that formatting (though I did not implement it since it requires tweaking the code in more places, instead of essentially modifying a single function like I did).

As we can implement this without additional flags (it doesn't contradict any style guide I know of), I think this would be strictly preferable.


Repository:
  rC Clang

https://reviews.llvm.org/D43183





More information about the cfe-commits mailing list