Why Avoid The “else” Construct ?
Till now I have seen a fair amount of code, the good, the bad and o yes! the ugly and the really really ugly. Ok, so you are a programmer, what makes you think a chunk of code is "good" or "bad" ? - I haven't had the opportunity to discuss this with fellow programmers in detail, so I think the best way to air this would be to document this.
First thing that comes to my mind about good code is READABILITY ... it's imperative the code should be readable and understandable. This however, is automatically achieved when you follow the most optimum way of execution and is even prettier in OOP. Structured code provokes ugliness. And I have noticed that the code gets uglier when there are more and more if-elseif-else construct nesting. I have seen programmers abusing this construct a lot ! You are better off using a SWITCH-CASE construct (which should also be used if and only if necessary).
I know you must be thinking: So what's up with the "else" construct ? and what does this guy have against it ? - Well, in all honesty, I don't have anything against it. It's just that the "else" construct refrains me to write beatiful code
- Ask yourself, why would you need a lot of else statements anyways ? (do keep in mind that for menu choices you always have the good 'ol switch-case). This may not hold true when you are executing via the structured approach. When using OOP, it just doesn't make much sense. Of course, a simple "if-else" is ok as its simple and readable too. But when you are dwelling into if-elseif { if - else }-else { if - else } it becomes more complex and consequently turns into a nightmare. Imagine yourself trying to debug a 100 lines of code out which at least 40 are consumed by the nested "if" construct. Hehe, I know ! - It scares me too
So what does it mean when you have used nested "if-elseif-else" structure a one too many times ? I answer this based on my own code more than a year ago. It means:
1. You are not breaking down problems into smaller chunks, that's for sure! - consequently you have become that greedy Ostrich who swallowed the whole freshly baked potato! so obviously the aftermath is the same. You jump, cry and get frustrated when you need to refactor the code or even worst, debug it.
2. Poor design ! - Yes ! poor design ! I don't care if you agree with me here or not, but you don't have a robust and scalable design before you put your cowboy hat on and went riding that keyboard. You did not think twice before coding. The rationale goes like this: An "if-else" construct denotes a change in variables and you address that change by changing the execution flow. Making the right decisions when a change occurrs. In an OO way, that variable change denotes a "state" change. So you do what you should according to that particular state. Similar to your reactions based on your emotional state,
Happy => Smile || Laugh
, Angry => Frown || Break something || Punch someone
, Sad => Cry || Whiskey++
In OO you can actually encapsulate execution as behaviors according to the change in state. As a result, you design is robust and scalable. All you need to do is invoke the right behavior for the right state. For that you'd probably need a simple IF statement.
3. Obviously either you haven't heard or you aren't interested in the philosophy behind "return home early" - a term coined by Felix from debuggable.com - READ IT as it addresses programming psychology you might make use of.
Doh ! I've run out of time. I'm going to try to put some code slides up. You look at the code and decide for youself.
Recent Comments