“if” – only if …

Our crusade against control structures is progressing. We have seen places how we can eliminate many of instances of “not”,”goto”,”else” and “else if”.

Can we eliminate the mother of all logic – branching itself – or “if”?

Interestingly, my observation is that in most cases when we take a decision, it is more because the way our data is laid out. Most “if”‘s are avoidable!

No, I am not drunk.


If you are following the blog in chronological fashion, by now you must be convinced that wherever a decision tests equivalence (or !=), it must be converted to a switch-case statement and not into an “if”.


The simplest way of reducing “if”s is to attack the condition block and start reducing the complexity.

If you have a keen eye, you can see that

1. Just because someone chose not to write a function for the action block, all the conditions were forced into the condition block.

2. Again, in order to get all the parameters for those conditions, your current function has a large list of parameters.

3. The larger the list of parameter becomes, the more complicated gets the contract of the function. Who is going to do error checks on each parameter that comes in.

This sounds like perfect disaster recipe – and familiar, isn’t it?
How would converting the action block into a function help?

If it is an ORing

if (x == 3 || y == 5) {

/* code equivalent to foo(); */


Call to foo(); can be actually made where x becomes 3 AND y becomes 5.

In case of ANDing, it is similar logic.

if (x == 3 && y == 5) {

/* code equivalent to foo(); */


In many such cases, foo() could be called when x became 3 OR y became 5.

And yes, I am ignoring NOT. We have eliminated NOT.


“Life is not so simple!” you will say.

Let us attack the problem from another angle.

A procedural programmer often uses “if”s to determine the type of the data. “If the first two bits are 01, the caller is my girlfriend else my mother-in-law.”

On the other hand, an OO programmer will eliminate this dilemma by putting proper class hierarchy and design pattern. Sub-typing takes care of most decision needs.

If you can subtype, you can not only avoid most “if”s but also most of void pointers, type indicating parameters, typedefs and ?:’s.


Then there is a question of efficiency. Many of my friends argue that calling a function, more so a virtual function, is a wastage of time.

They fail to notice that functions with smaller signatures (and less contract) are likely to execute faster because need of communication through stack operations goes down significantly – and there is less code to check the contract. Even in case of RISCs where pushing on a stack is not so common, frames do rearrange data between registers.

As a matter of fact, after converting one of Tcl procedural applications into STOOOP code, we have seen 20% increase in code efficiency. My guess is that efficiency conscious C to C++ gain must be more impressive than implementation conscious Tcl to STOOOP gain.


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