Side effects of multiple If then else

Scenarios

In modern application development, writing code which is modular and simple is a greatly appreciated. But once it comes to handling business scenarios or handling scenarios where we have to perform decision making in the code, then we simple write IF THEN ELSE in code.

If the code in your method is small, it doesn’t show you the pain. But once the code keeps growing to hundreds or thousand line of code and similar scenario handling comes, we again add the same IF THEN ELSE. This can become a pain and your if then else is in multiple places.

Lets put a utility code

Now, I know what you will say, let’s a add a helper method or a utility code which can do a decision making. Yes, I agree on this, but now this thinking is telling us that we are heading towards a design pattern where we do a decision making to handle appropriate flow.

If we do not make such changes then we may end up adding similar scenario handling into entire code base, or call it as your duplicate code which will bleed into multiple areas in your software. God forbid it you forget to make change at one place out to five, then you code will not work the way it is supposed to.

What should I do then?

Hence, it makes sense to take a step back and see if we can simply write a strategy pattern code or some sort of template code which is doing decision making only at one place . Other parts of the code will use this code and no need to implement it on their end.

This approach helps in code maintenance and keeping is under the rules of SOLID design principles.

I am also a culprit of writing code similar way and therefore wanted to share g my experience based on so many code reviews and lines of code I have seen in my professional career so far.

I always try to tell myself ..Can I keep it Simple and Stupid?