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

Wentao Shang wentaoshang at gmail.com
Wed Aug 12 11:56:28 PDT 2015


Two comments:

1) In terms of indentation and placement of curly braces, I prefer option A
or D but with extra indentation for statements inside the switch block.
This should fix the issue of having two closing braces at the same level.

2) Mixing block and non-blocked statements under the same case clause seems
confusing. I would suggest we mandate that if block is used inside the case
clause, it should always cover the entire case clause.

Wentao

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

> Dear folks
>
>
>
> rule 1.10 gives two forms for switch statements. The preferred form is:
>
>
>
> switch (cond) {
>
> case 1:
>
>   stmts;
>
>   // Fallthrough
>
>
>
> case 2:
>
>   stmts;
>
>   break;
>
>
>
> default:
>
>  stmts;
>
>   break;
>
> }
>
>
>
> In reality, ‘stmts;’ may need to declare variables, but declarations are
> disallowed directly under a ‘case’ label.
>
> The solution is to use a compound statement { stmts; } , inside which
> declarations can be used.
>
>
>
> My question is, how to properly indent a switch statement in which some
> ‘case’ labels have compound statements?
>
>
>
> I prefer the following form:
>
>
>
> // option A
>
> 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;
>
> }
>
>
>
> I have also seen:
>
>
>
> // option B
>
> 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;
>
> }
>
>
>
> // option C
>
> 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;
>
> }
>
>
>
> // option D
>
> switch (cond) {
>
> case 1:
>
> {
>
>   int i = 1;
>
>   doSomething(i);
>
>   // Fallthrough
>
> }
>
>
>
> case 2:
>
>   doSomething(2);
>
>   break;
>
>
>
> case 2:
>
> {
>
>   int j = 3;
>
>   doSomething(j);
>
>   break;
>
> }
>
>
>
> default:
>
>  doSomething(0);
>
>   break;
>
> }
>
>
>
> Option B exactly matches rule 1.10 because a compound statement, by
> definition, is a statement. However, it’s less readable than option A
> because the actual statements under a ‘case’ label with a compound
> statement is indented more than the statements under a ‘case’ label without
> a compound statement.
>
> Option C has the same problem as option B, and also has hides ‘break’ or
> ‘// Fallthrough’ inside the compound statement making them less visible.
>
> Option D looks okay but in case the last ‘case’ or ‘default’ label
> contains a compound statement, two ‘}’ would be indented at the same level
> at the bottom, which is confusing.
>
>
>
> What do others on the mailing list think about this?
>
> I intend to amend rule 1.10 when a consensus is reached.
>
>
>
> 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/f5c73c2e/attachment.html>


More information about the Nfd-dev mailing list