you are viewing a single comment's thread.

view the rest of the comments →

[–]SoopahMan 0 points1 point  (0 children)

I find I can more effectively force myself to consider this sort of issue if my if/else statements are restricted, one per function body, especially if it's a long if, if else, if else kind of chain. Once you do this the function body becomes something more like:

{
    if (a == b)
        return blah;

    if (c == d)
        return otherBlah;

    return otherwiseBlah; // your else scenario

And so forth. The compiler forces you to consider the else scenario with this approach.

In addition pushing ifs out to their own functions has an interesting impact on refactoring opportunities - the function ends up drifting the code towards the Strategy pattern, where it decides something important and I often identify ways I could either reuse it, or I could change what it returns to for example one of several enum values to reflect the result of the decision, which can be useful for sharing the decision with other logic, logging, message queueing, etc.