What is the best way to replace or substitute if..else if..else trees in programs?

Question

This question is motivated by something I\'ve lately started to see a bit too often, the if..else if..else structure. While it\'s simple and has its uses, somet

Answer 1

I use the following short hand just for fun! Don't try anyof these if code clearity concerns you more than the number of chars typed.

For cases where doX() always returns true.

i==1 && doOne() || i==2 && doTwo() || i==3 && doThree()

Ofcourse I try to ensure most void functions return 1 simply to ensure that these short hands are possible.

You can also provide assignments.

i==1 && (ret=1) || i==2 && (ret=2) || i==3 && (ret=3)

Like instad of writting

if(a==2 && b==3 && c==4){
    doSomething();
else{
    doOtherThings();
}

Write

a==2 && b==3 && c==4 && doSomething() || doOtherThings();

And in cases, where not sure what the function will return, add an ||1 :-)

a==2 && b==3 && c==4 && (doSomething()||1) || doOtherThings();

I still find it faster to type than using all those if-else and it sure scares all new noobs out. Imagine a full page of statement like this with 5 levels of indenting.

"if" is rare in some of my codes and I have given it the name "if-less programming" :-)

Answer 2

These constructs can often be replaced by polymorphism. This will give you shorter and less brittle code.

Answer 3

Outside of using a switch statement, which can be faster, none. If Else is clear and easy to read. having to look things up in a map obfuscates things. Why make code harder to read?

Answer 4

In OO paradigm you could do it using good old polymorphism. Too big if - else structures or switch constructs are sometimes considered a smell in the code.

Answer 5

The switch statement of course, much prettier then all those if's and else's.

Answer 6

The example given in the question is trivial enough to work with a simple switch. The problem comes when the if-elses are nested deeper and deeper. They are no longer "clear or easy to read," (as someone else argued) and adding new code or fixing bugs in them becomes more and more difficult and harder to be sure about because you might not end up where you expected if the logic is complex.

I've seen this happen lots of times (switches nested 4 levels deep and hundreds of lines long--impossible to maintain), especially inside of factory classes that are trying to do too much for too many different unrelated types.

If the values you're comparing against are not meaningless integers, but some kind of unique identifier (i.e. using enums as a poor man's polymorphism), then you want to use classes to solve the problem. If they really are just numeric values, then I would rather use separate functions to replace the contents of the if and else blocks, and not design some kind of artificial class hierarchy to represent them. In the end that can result in messier code than the original spaghetti.