Avoiding elif and ELSE IF Ladder and Stairs Problem

This article focuses on discussing the elif and else if ladder and stairs problem and the solution for the same in the C and Python Programming languages.

The ELIF and ELSE IF Ladder and Stairs Problem

There are programmers who shy away from long sequences of IF, ELSE IF, ELSE IF, ELSE IF , etc. typically ending with a final ELSE clause. In languages with ELSE IF or  elif syntax, the pattern is called an “ELSE IF ladder.” In languages without ELSE IF or elif , each conceptual ELSE IF is written as an IF placed within the  ELSE  part of its predecessor. With indenting, it looks like descending an upside-down staircase.

• This forms an undesirable, hard-to-read, worse-to-enhance, error-prone programming structure. 
• With indenting, the staircase code falls off the right side of the screen. 
• For some programmers, the problem is esthetics, while others worry about maintainability. 
• Sometimes, the syntax genuinely gets in the way of expressing the logic that needs to express. 

Fundamentally this pattern expresses both prioritization and a short-circuiting: 

• The prioritization is that statements are processed only for the first TRUE among a set of conditions. 
• The short-circuiting is that after the first condition is found to be true, no further test condition expressions are even evaluated. This matters because condition expressions may invoke some functions, such as IF (42 < somefunction( x ) ). . . , where some functions might be stateful and have side-effects. 

Any alternative must maintain these semantics. Furthermore, sometimes there are statements that need to be executed only if some prior conditions fail, but need to execute for all the later conditions. 

Example: 

Note that this repetition of statements that apply to each of the later possibilities ( a = 45 ) violates the “Don’t Repeat Yourself” (DRY) principle. Any change must be repeated after each condition.

Two-step Approach To Eliminate ELSE IF and ELSE 

Instead of the ELSE IF and ELSE code above, the following approach eliminates the need for them, while keeping the prioritization and short-circuiting semantics:

1. Place a set of independent IF statements within a single-iteration loop.  Do not use any ELSE IF or ELSE syntax. 
2. Add a loop exiting statement as the last of the statements within each  IF.  BREAK is preferred to  CONTINUE. The python code offers a for and a while version of the loop. BREAK must be used with the while version of the loop.

Example:

Explanation: We rarely, if ever, intentionally code a loop that will always be used for exactly one iteration, but here we do that. Most programming languages provide a loop control statement, such as BREAK to exit a loop completely, or CONTINUE, to jump to the loop’s next iteration. However, in this one-pass loop usage, there will not be and must not be any next iteration. 

This solution exploits these iteration statements in place of ELSE IF and ELSE. The BREAK, or CONTINUE statement causes all further statements inside the loop to be bypassed. When the loop is specified so as to have only one iteration, even a CONTINUE statement leads to exiting the loop. 

In the code sample, either CONTINUE or BREAK will work with the C version or the for loop version in python. The while loop python version requires the use of the break statement, including one after the final else-equivalent statements. 

Also, in between the IF statements, there can be additional statements that execute before testing any of the later conditions.  

Processing Cost or Overhead: The python version does experience the minimal overhead of setting up the loop. The overhead in C is even less, and if using a clever optimizing compiler, there might be no overhead at all.

Summary

At first glance, this idiom looks like an unnecessary trick. Upon more careful consideration, it makes the application easier to understand and maintain. I would use it with compiled languages, especially with an optimizing compiler. I would also use it in interpreted languages, except in a performance-critical hotspot. Even there, I would use it initially and revert to if, elif, elif, elif … else only after full application debugging.