[webkit-dev] Resolution on switch statement indentation

Maciej Stachowiak mjs at apple.com
Wed Dec 9 12:57:58 PST 2009


On Dec 9, 2009, at 10:11 AM, Chris Marrin wrote:

>
> On Dec 9, 2009, at 9:41 AM, Maciej Stachowiak wrote:
>
>>
>> I meant 4 spaces from the switch (i.e. 2 additional spaces from the  
>> case label).
>>
>> switch (x) {
>> case foo: {
>>   fooFunc();
>> }
>> case bar:
>>   barFunc();
>> }
>
>
> Ok, the example above seems to be missing a space (it indents the  
> case label 1 and the block 3). But I assume you meant to indent 2  
> and 4. If so, I understand what you are proposing. I still don't  
> like it, but I understand it. I think a consistent 4 space  
> indentation scheme avoids confusion and makes all the indentation  
> tools in editors work correctly. If excessive indentation really is  
> that big of a concern (which I don't think it is) I would rather see  
> the current rule (rule 1) used.

Just to be unambiguous, here is my proposal set in a monospace font:

01234567890123456789
switch (x) {
   case foo: {
     fooFunc();
   }
   case bar:
     barFunc();
}

(Hoping this doesn't get mangled in email.) Reasons I suggested this  
rule:

A) Actual statements end up indented 4 spaces, preventing excessive  
indent, and perhaps aiding readability in the no-brace case.
B) You can't end up with a brace at the same indent as the switch that  
doesn't actually close it; or two braces at the same indent level in a  
row.

I think using a partial or half indent for case labels is not a wild  
or uncommon style. Some also use half-indents for goto labels, but no  
one seems to have a problem with leaving those unindented as far as I  
can tell.

That said, if no one prefers this to the status quo, we should stick  
to the current rule. But I don't think we should allow multiple  
different indent styles.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091209/116b7f30/attachment.html>


More information about the webkit-dev mailing list