re: Keeping your code clean by sweeping out "if" statements VIEW POST

re: One downside to the map version is it's less flexible. Are you certain you'll never need to enhance one of those conditions? Should you ever get ...

I don't agree you would have to refactor it back to sequence of ifs. Instead, you either have just one or 2 ifs before the call, better than 10 ifs! And when you get to the point where you have several ifs between the lookup and the call, it's time to refactor the special cases into the function calls themselves, then you're back to 0 ifs.


In my opinion, now you have the mental burden of both approaches.

Personally, I'd want to choose one.

In my point of view, if you have to have a couple of if-statements before checking the map, that's a sure sign that the map is the wrong abstraction - for example, maybe the type inside the map is the wrong type and you may need to consider adding more abstraction, e.g. a type that covers all your cases; again, being aware of the complexity trade-off.

Maybe it's worth it, maybe it isn't. This is where the job gets hard 😉

Code of Conduct Report abuse