Actions
Forum Thread Details
  • Replies 15 replies
  • Subscribers 387 subscribers
  • Views 2823 views
  • Users 0 members are here
Related

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

colporteur 

if (digitalRead(ButtonPin) == LOW) {  //}

OR

if (digitalRead(ButtonPin) == HIGH) {  //
  return HIGH;
} else {  //}

I came across these two methods of testing a button. They both accomplish the same thing. 

Why would a coder use one over the other? What are advantages/disadvantages to using either?

I am a code resurrectionist not a programmer or coder. I usually cut and paste code parts to develop a working project. I have code that use both methods. I'm curious what falls into best practice? Does one provide better performance?

Parents

  • 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.

Reply

  • 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.

Children
  • in reply to Fred27

    I agree with   and  

    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 Wink 

    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.