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

[Eric Newberry]

I agree completely with Wentao on the second comment. Mixing the two 
styles would lead to confusion.

--
Eric Newberry

Computer Science Undergraduate
The University of Arizona
Vice President, University of Arizona ACM Student Chapter

On 8/12/2015 11:56 AM, Wentao Shang wrote:
> 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 <mailto: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
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150812/c0ceae09/attachment.html>