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

[Eric Newberry]

I would argue for Option D, as the alignment of the braces fits more 
with the preferred style for statements in ndn-cxx (although with the 
opening brace on a new line instead of the same one). Also, unlike 
Option A, the break statement is inside the compound statement. I feel 
that having the break outside of the statement could lead to confusion.

However, I do agree that having two closing braces at the bottom could 
be confusing. As such, I'd suggest changing Option D to indent the 
contents of the switch statement one level to avoid this confusion.

--
Eric Newberry

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

On 8/12/2015 7:13 AM, Junxiao Shi 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
>
>
>
> _______________________________________________
> 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/29853422/attachment.html>