views:

316

answers:

3

What is the difference between nested and cascaded if-else?

+4  A: 

These two are equivalent:

if (condition1) block1 
else if (condition2) block2


if (condition1) block1 
else
{
   if (condition2) block2
}

I presume they also compile to the same assembly, so there should be no difference.

abc
Wouldn't this depend on the specific language? Although I can't think of a language where you aren't correct, I can surely create one :-)
Rune
+1 for the compilation part
Oskar Kjellin
Rune, you are right! :) But C-syntax has taken over the world now. Where is old cobol without arithmetic symbols...
abc
+1  A: 

I depends on how you arrange them. A nested if is equivalent to adding an and to each of the inner ifs:

if(A) {
    if(B) {
        statement1
    }
    else if(C) {
        statement2
    }
}

is equivalent to:

if(A and B) {
    statement1
}
else if(A and C) {
    statement2
}

My advice is to strive for readability and check your logic. You may find DeMorgan's Laws useful for re-arranging your logic.

Here's one that always irritates me:

if(A and B) {
    statement1
    statement2
}
else if(A and C) {
    statement1
    statement3
}
else if(not A) {
    statement4
}

vs

if(A) {
    statement1
    if(B) {
        statement2
    }
    else if(C) {
        statement3
    }
}
else if(not A) {
    statement4
}

I'm just not sure which is more readable. They are logically equivalent. The first is more tabular and easier on the eye but repeats statement1; the second is more nested and a little uglier (to my eye) but does not repeat statements. Ultimately it's a judgment call because it makes no difference to the compiler.

charlieb
A: 

Nested if-then-else control structures are minimized translations of complex logic rules. They are good in avoiding redundancy in checking conditions. Their main drawback is that in the long run these structures can grow and make enclosing methods too big and complex. First step in breaking nested if-then-else blocks is normalization. For example:

if (A) {
  if (B || C) {
    block 1;
  } else {
    if (!D) {
      block 2;
    }
  }
} else {
  block 3;
}

can be normalized to cascaded if-then-else

if (A && (B || C) {
  block 1;
  return;
}
if (A && !B && !C && !D) {
  block 2;
  return;
}
if (!A) {
  block 3;
}

We have eliminated else blocks and made further extract method refactoring easy. All three if blocks can be extracted to separate methods named after the business logic their bodies execute.

Boris Pavlović
I like this idea but I think going that far should be for guard clauses only rather than core function logic. Plus many corporate environments place restrictions on the number of returns a function can have so this approach may not fly.
charlieb
I've seen methods growing like cancer after some time due to nested if-then-else clauses. When they have to be maintained by many people nobody has courage or will to split them to several methods. 'Normalization' enables this refactoring and making the code better on the end.
Boris Pavlović
Tests are a wonderful substitute for courage.
Wayne Conrad