[Nfd-dev] code-style: switch with compound statement
Eric Newberry
enewberry at email.arizona.edu
Wed Aug 12 11:59:22 PDT 2015
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>
More information about the Nfd-dev
mailing list