More configurability for indentation for switch statements

For block-structured languages like C, C++ and Java, there is disagreement about indentation for switch statements (e.g., see FP on squid:IndentationCheck with switch case indentation).

Let’s say you’ve set the indentation to 4 in rule java:S1120 (or its equivalent in another language with similar syntax for compound statements). Now take this ultra-simplified example:

/1/ switch (foo) {
/2/ case BAR:
/3/ i++;
/4/ }

If following one-true-brace, everyone would agree lines 1 and 4 would have the same indentation, and that at least line 3 should have more indentation than 1 and 4. But people disagree on the details.

Option 1:
If you view the contents of a switch statement according to its syntax, as a block, then everything inside the block should be indented. So some people would indent both 2 and 3 by 4 spaces more than 1 and 4.

Option 2:
Then again, others view line 3 as being subordinate to line 2, so they would indent line 2 by 4 spaces and line 3 by 8 spaces. (I believe this is how rule S1120 interprets this.)

Option 3:
If you consider the semantics of the switch statement, it is basically a specialized if-then-else. In that case, it doesn’t make sense to indent line 2, because line 2 is part of the control structure rather than the “body”; one would no more indent line 2 than indent an “else” any further than its corresponding “if.” This is how the Sun/Oracle coding guidelines do it.

Option 4:
And then there are those who go for a compromise: indent line 2 by 2 spaces and line 3 by 4 spaces. This then makes visually clear that, control-wise, line 3 is directly underneath line 1, rather than being 2 levels down as would be implied by indenting 8 spaces. Also, it keeps the total indentation down (which is why people tend to avoid setting the indentation to 8 in general). Yet it still sets the case tags off from everything else.

So what I would suggest is adding to rule java:S1120 (and its equivalent in other relevant languages) two separate parameters for the desired indentation for 1) the case tags, and 2) the case statements.

For my examples, assuming the main indentation level is 4, the settings for these two parameters would be:

Option 1: 4,4
Option 2: 4,8
Option 3: 0,4
Option 4: 2,4

Hi @MisterPi,

Thank you for reporting this problem.

I agree that the way this rule behaves is not consensual. Switch statements are just one example where this happens. However we do not not plan to make this rule more configurable. To fit everybody’s needs the rule would require so many parameters that it would become unusable. It is currently an opinionated rule which is disabled by default. Developers who agree with the way it works can activate it.

Our current focus is on the detection of bugs, vulnerability and maintainability issues. Sadly styling rules are rarely consensual so they have a low priority right now. We’ll keep in mind your feedback when we start working on styling rules again.