I'm quite new to coding and I've never understood what's the proper way to do the following:
if (something == true) {
DoSomething();
} else {
if (something2 == true) {
DoSomething2();
}
DoSomethingAnyways();
}
I've heard using else if is the right way to do this, but how can I execute the DoSomethingAnyways(); if I use else if?
Basically what I'm asking is how can I write this using else if and have the exact same effect?
if (something == true) {
DoSomething();
} else if (something2 == true) {
DoSomething2();
DoSomethingAnyways(); //<-- Where do I put this line of code?
}
Under the assumption that you want
then your code is the way to go.
if (something == true) {
DoSomething();
} else {
if (something2 == true) {
DoSomething2();
}
DoSomethingAnyways();
}
Using "Else If"
If you don't want to use nested ifs, you could write this, which has the same effect as your original code:
if (something == true) {
DoSomething();
} else if (something2 == true) {
DoSomething2();
DoSomethingAnyways();
} else {
DoSomethingAnyways();
}
However this adds complexity when it comes to maintenance. Imagine that in a few months, you need to add code to perform an action before DoSomethingAnyways(). You potentially have to maintain two branches - the "else if" and the "else" branch - making your code more and more complex. You might forget about updating one branch, because the dependency is no longer obvious - and that introduces a bug.
Code Complexity
It's true that nesting ifs makes your code harder to read - and there is a metric for that: the cyclomatic complexity (independent paths through your code). However, in your case the cyclomatic complexity is the same, whether you use else-ifs or the else with the nested if - you have 3 independent paths. Generally you should consider splitting up your code once you reach 10, so you'd still be far away from that. In this case, the cyclomatic complexity is low, and your code is easy to grasp, so I wouldn't worry about it.
I personally find your original code "prettier" than an else-if/else, because it describes the dependency better (you call "DoSomethingAnyways()" regardless of whether something2 is true, but you do the whole DoSomething2/DoSomethingAnyways only if something is false).
Refactor the else branch info a function
If you are worried about nesting ifs too much, refactor the else branch info a new function:
if (something == true) {
DoSomething();
} else {
DoSomething3(something2);
}
function DoSomething3(something2) {
if (something2 == true) {
DoSomething2();
}
DoSomethingAnyways();
}
There is a small overhead for calling functions, so I wouldn't take it to the extreme - use your own judgement. If you think "oh I wonder if I'm still going to get that in a year", then you should probably reduce complexity (and document your work, using comments).
Either way you do it - with the else and the nested if, or the function - both fragments of code you'll read in months, and likely still grasp the dependency quickly, and you don't run into the risk of forgetting to update one branch when you change your code in future.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With