If-else keyword built into nearly every programming language and simple conditional logic are easy for anyone to understand. If you are a programmer, you know else keyword. But if you are a good programmer, don’t use this keyword. One of the biggest mistakes I fell into when starting was overusing the else keyword when writing conditionals. I stopped using this keyword in my programs since 5 years ago. Let me explain!
Why?
Think about what else means, it means “if A then this, if not A then that;”. This isn’t a problem if A is binary — the problem space is only 2 cases. But if A is a combination of binary variables, or contains larger variables, your negative problem space can be unexpectedly large and difficult to understand, test and maintain.
To avoid if/else if, to only use if statements, to spend the time to ensure the entry criteria for your group of if’s are mutually exclusive so that the answers don’t depend on the order of execution.
- It promotes the main execution lane, with a few special cases.
- It forces us to write all conditions, required to process the data, at the beginning of each function.
- Use a switch — case statement.
- Use polymorphism to handle complex conditional cases, making the code more clear like State Pattern.
Examples
Our example is a traffic light (i.e. TrafficLight object) with 3 different states: Red, Yellow and Green, each with its own set of rules. The rules go like this:
- Say the traffic light is Red.
- After a delay the Red state changes to the Green state.
- Then, after another delay, the Green state changes to the Yellow state.
- After a very brief delay the Yellow state is changed to Red.
- And on and on.
Don't use if-else keyword
The simple way
We only remove else keywords and re-write all conditions.
Or we can use a switch instead of if-else. A switch looks much cleaner when you have to combine cases. A if-elsewill quickly get out of control.
A switch statement might prove to be faster than if-else provided a number of cases are good.
The style conventions are.
- Aligning each case with switch.
- Indenting the code within each case.
- Ending each case with a clear break.
- Avoiding fall-throughs.
- Ending the switch with a default, to make sure there’s always a sane result even if none of the cases matched.
We can use the State Pattern to remove all if-else keyword in these codes
Here, we introduce lots of if-else blocks/switch statements to guard the various conditions. The state pattern¹ fits in such a context. It allows your objects to behave differently based on the current state, and you can define state-specific behaviors. In this pattern, we start thinking in terms of possible states of our traffic light, and you segregate the code accordingly.
- For a state-specific behavior, you have separate objects.
- Operations defined in the traffic light are delegating the behavior to the current state’s object.
- States are triggering state transitions themselves.
Traffic Light: Green (1 minute) → Yellow (10 seconds)→ Red (1 minute)
They are print the same output as following.
It is these examples of bad codes and good codes. Finally, thanks for reading and hopefully I’ve covered everything.
- [1] Erich Gamma & Richard Helm & Ralph Johnson & John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994.