“else” – minimize surprize

Have you ever felt irritated calling up an 800 number when the option you are often interested is at the last and the line does not recognize button press till it is done speaking.

The same is true for “else” statements. So often we see that we are interested in default behavior of the code – and it is available only at the end of 500 line if-else if-else chain.

if ( condition1 )

… /* take action responding to the condition */

else if ( condition2 )

… /* take action responding to the condition*/

else

foo(); /* default action */
Good code should not have last “else” part. Why? Because an unconditional “else” – “for every other case” – often spells unthought out situations. Such situations turn Sphinx and pose riddles when “else” part of the code needs to be further split for feature additions. Also, “else” fires at most unopporune moments when none of above conditions were met and you were truly clueless about “else”‘s side effects.

Instead, I suggest eliminating “else”. This is how.

bar (); /* prepare for default behavior – set flags to describe the situation */

if ( condition1 )

… /* set flags to describe the situation */

else if ( condition2 )

/* set flags to describe the situation */

/* code to handle the conditions set by above blocks */
And the code inside conditions is modified in such a way that they signal a common code segment following the block rather than taking any direct action.

Ideally the action block that follows the situation is nothing but a function pointer, executing a piece of code fixed by the decisions.

This approach has two parts – modifications in decision as to raise only the flags and coming up with an action block that caters to all conditions.

There may be a doubt that when one of “non else” conditions could be true, we are executing more than necessary – first assigning defaults and then assigning condition specific code.

However, if you go thorugh the above approach carefully, it is not too much of execution overload as all you are doing is setting appropriate flag.

The second problem is with too long an “if-else if” chain, which might in turn result into huge function table. I acknowledge that a large array of function pointers might be difficult to debug for those who don’t like function pointers.

However, we should also consider that creating an array of function pointers isolates the “business logic” from the “implementation logic” – or separates “rules” from “data”.

This separation is invaluable. Maintenance of such a code becomes a breeze. As a matter of fact, if you are lucky to have a project in a language which supports associative arrays (like Tcl or Perl or PHP), you can eliminate the entire “if-else if-else” chain altogether. This is a topic of yet another discussion.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s