Is this a case where 'else' is inevitable?

Question

I am writing some code that enables / disables a certain kind of hardware function. To enable it on, I have to call some methods, and to disable it, some others.

Of course I want this code to be clean, so I try to keep the use of if/else to a minimum. See Elegant ways to handle if(if else) else and Clarification of "avoid if-else" advice for discussions about this.

void LightTest(bool enable) {
    if (enable) {
        TurnOnAllLights();
        SetValueOnAllLights(1);
    } else {
        TurnOffAllLights();
    }
}

However, this seems like a case, where I cannot avoid using else. The question is, is this true?

Answer 1

This is a misleading assumption. Removing else statement does not make the code cleaner. It just increases the risk of mistakes.

For a detailed discussion, see for example the recommendation MSC01-C from the CERT C secure coding standard, which explains that the code should strive for logical completeness, as vulnerabilities can result when failing to consider all the possible alternatives. In this regard, the else visibily demonstrates that you have considered them.

Proof by contradiction

Let's have a look at your code, and see how you could avoid the else. The systematic approach is to llok at the possible execution graphs and regorganize them to produce an equivalent graph.

A first approach is to add a conditional for the contrary:

if (enable) {
    TurnOnAllLights();
    SetValueOnAllLights(1);
} 
if (!enabled) {  // ====> OUCH ! super risky 
    TurnOffAllLights();
}

Rewriting the code like that removes the else, but it is super risky. Not in your small snippet, but in real-world if statements, in the case where the first if-block would change the value of enabled, which will result in both blocks being run instead of one of the two.

A second approach is to use a premature return

if (enable) {
    TurnOnAllLights();
    SetValueOnAllLights(1);
    return;   // ===> HORRIBLE IN THIS CASE
} 
TurnOffAllLights();

It's not always bad to prematurely return. But in this case it is it is: it requires more brainpower to understand that it's just about an alternative. Moreover, you may multiply unnecessarily function exit points, which is not a very popular nor effective practice either. Furthermore, how would you do if you'd still have a common part of code to run after the else? Copy-paste it and repeat yourself with all the risks that it represents for the future?? This is especially tricky if this additional ode would be added later, bearing the significant risk of forgetting it in one of the branch.

Now the finale, the return to the good old GOTO; really?

if (enable) {
    TurnOnAllLights();
    SetValueOnAllLights(1);
    goto GREAT_SPAGHETTI_CONTINUES;
} 
TurnOffAllLights();
GREAT_SPAGHETTI_CONTINUES: // OUCH! 
//...
}

I'll not analyse this snippet, but just remind that it took a decade to get rid of problem-solving-by-adding-another-goto, to finally discover the virtues of structured programming. Let's not go back to wild-goto age. Again, there are cases, where the use of goto could be discussed, but avoiding the else definitively isn't.

If you could change more than the control flow

I cannot resist but to delegate the setting of the light to a single function:

TurnAllLights(enabled); // incl.responsibility for setting value correctly 

Answer 2

If it's a pure on/off scenario, a function called toggleLights() would be sufficient instead of turnon/turnoff. There wouldn't be a need to pass around a boolean. In the value for lights set value the to the inverse like:

x = !x;

That should be sufficient and there would not be a need to have a conditional. Now if you needed to do some additional logic based on the new value of the setting, maybe then you would need a conditional to inspect that current value.