Coding with else{}...what are the cost benefits analysis?

Hi Sean,

There's not much difference, one might be a fraction faster or slower but it's negligible. It also depends on if the push-button is wired to ground or to the supply.

Everyone does it in different ways, personally I just bury that detail in the #define section, approximately like this:

//****** Definitions ******
#define BUTTON_PIN 10
#define BUTTON_PRESSED (digitalRead(BUTTON_PIN)==LOW)
#define BUTTON_UNPRESSED (digitalRead(BUTTON_PIN)!=LOW)

//****** Code ********
if (BUTTON_PRESSED) {
// do whatever
}

(Cant see the Editor toolbar, otherwise I'd format it as code!). 

My first thoughts are:

1) When you know that there is a dominant state, where the button spends more time in, put this one into the if clause to make the code a little more performant. This is especially true if there are 'else if' statements present.

2) Put the active state into the if clause to make the code better understandable. 

If it is a button I try not to read and compare the state in the if statement but to compare against a state variable of the button. In this way I can add logic to prevent button click bounces or have logic to disable or enable the button. If I can also transfer the detection of button changes to an interrupt service routine, or ISR instead of having to continuously poll the button's status, all the better.

Code readability and maintainability will trump any minor performance differences in almost all cases. Make sure your code is easy to follow, debug, and extend and all will be good.

Exactly what code style you follow to do this doesn't really matter. If you're adding to someone else's code then it's often good to follow the same style - even if there's another style you would prefer if starting from scratch.

That hanging else will almost certainly be optimise out by the compiler as it does nothing.  Therefore, it will come down to preference and whether you feel it makes the code clearer (I don't think it does.)  In a professional environment, coding standards would either insist it isn't written like this or insist it is! In over 30 years, I've NEVER seen hanging ELSE statements written.

I agree with Fred27  and Andrew J 

The optimizer will remove the empty “else” parts, so it’s not any concern in final performance.

And code must be readable if you wish to have any chance of maintaining it, unless you’re specifically being cryptic for job security  

I have used the empty else when adding comments as to what the else situation is or isn’t. Although that’s usually only a comment, not actual code:
// else this is not a duck. Ignore.

I’ve also used it to allow for easy addition of debug  statements, but the whole else block then usually gets removed when it’s no longer necessary. But I might keep it around long enough to finish development first.

Sometimes I’ll leave an else with a comment when a future iteration “should probably” do something in that case, like report an error to the server.

There’s a good chance my e14 project code has empty else blocks in it simply because I don’t clean it up as much as I would with my production code. The examples provided also often have the empty else as a way to teach those who are learning that the opportunity exists there to check something or do something.

My understanding is by using the second conditional statement provides more flexibility. With the else, you provide the option to take action on both a HIGH and LOW value of the button. The first conditional statement doesn't provide that. 

The Best practice for a coder would be to provide flexibility without causing overhead. By using the conditional statement with else the code is more flexible to expand. If never needed nothing lost.

Oh! Sorry I think we may have been overthinking your question!

Yes, using if…else allows two possible actions for just one comparison.

But it’s trivial to simply add the else part later if you need it, so I generally don’t add it except for my reasons above.

It seem I always manage to corrupt the bracket count and thing go for spiral.

Those of us who are used to programming with object-oriented languages try to program without using conditional statements (if, case) to minimize branching. A conditional statement generates several paths and therefore when testing you have to test all those paths. This complicates the tests. In object-oriented programming, this is not your case, a good practice is to replace branching by polymorphism.

See: https://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html