[Nfd-dev] code-style: switch with compound statement

Wentao Shang wentaoshang at gmail.com
Wed Aug 12 16:00:59 PDT 2015


On Wednesday, August 12, 2015, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
>
>
> Incorporating suggestions from Eric and Wentao:
>
>
>
> // option E
>
> switch (cond) {
>
>   case 1:
>
>   {
>
>     int i = 1;
>
>     doSomething(i);
>
>     // Fallthrough
>
>   }
>
>
>
>   case 2:
>
>   {
>
>     doSomething(2);
>
>     break;
>
>   }
>
>
>
>   case 3:
>
>   {
>
>     int j = 3;
>
>     doSomething(j);
>
>     break;
>
>   }
>
>
>
>   default:
>
>   {
>
>     doSomething(0);
>
>     break;
>
>   }
>
> }
>
>
>
> ·         When any ‘case’ or ‘default’ contains a declaration and
> therefore needs a compound statement, all ‘case’s and ‘default’ must use
> compound statements.
>
I wouldn't go that far as to require all cases to have the same format. I
think it's ok to mix blocked case and non-blocked case, as long as the
block covers the entire single case branch. But the current specification
(option E by Junxiao) also looks fine to me.

> ·         When using compound statements, ‘case’ and ‘default’ should be
> indented two spaces after ‘switch’, ‘{‘ and ‘}’ of the compound statements
> are indented at the same level as ‘case’ and ‘default’, and statements
> within the compound statements are indented two spaces after ‘case’ and
> ‘default’.
>
> ·         ‘break’ and ‘// Fallthrough’ should be placed inside compound
> statements.
>
I would suggest one more readability requirement: any intentional
fall-through MUST be explicitly annotated in the code. (Do we have this
rule already? I can't remember.)

Wentao

>
>
> A ‘switch’ statement without compound statements should still be formatted
> in the current way, i.e. no extra indentation for ‘case’ and ‘default’.
>
>
>
> Any more comments?
>
>
>
> Yours, Junxiao
>


-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150812/8afa5882/attachment.html>


More information about the Nfd-dev mailing list