At the beginning of our career, every developer learns the if else
conditionals and immediately start using it everywhere. I would say it is normal because the use case is quite simple to understand, "if the condition is true, then do this, otherwise, do something else".
You can even easily identify a code written by a junior developer just reading all the if else
used in their code. This is normal and part of the learning process. But as we gain more experience we learn better ways to do the same things.
The problem with the else
is that it doesn't have the proper context as it's own, and you always must back to if
to remember what it does. And, in many cases, it is completely useless, as I will show you.
The not necessary case
Consider the following code:
func multiply(ifExists value: Int?, by: Int = 2) -> Int {
if let value = value {
return value * by
} else {
return 0
}
}
It's a simple Swift function with an optional parameter (the Int? describes it if you are new to Swift).
If the parameter is not nil (mainly known as null) multiply it by the second parameter (which is not optional but have a default value 2). But if the parameter is nil then return zero as a result.
Wait a minute... is the else
statement necessary in this code? It is not. We can easily refactor this to return right after the if
statement:
func multiply(ifExists value: Int?, by: Int = 2) -> Int {
if let value = value {
return value * by
}
return 0
}
Much cleaner, right?
In Swift, you can also use guard, if you prefer (I like this one):
func multiply(ifExists value: Int?, by: Int = 2) -> Int {
guard let value = value else { return 0 }
return value * by
}
The return earlier case
Every time you collect user input you will need to validate it before using it. It is very common to see codes like that:
func submit(email: String, phone: String) -> Void {
if isValidEmail(email) {
if isValidPhone(phone) {
doSomething(email: email, phone: phone)
} else {
displayPhoneError()
}
} else {
displayEmailError()
}
}
Two properties and two else
cases. It works, but we have to follow two indentation levels to read every line and understand what is going on.
I think it is better to read if we refactor the function to:
func submit(email: String, phone: String) -> Void {
if !isValidEmail(email) {
displayEmailError()
return
}
if !isValidPhone(phone) {
displayPhoneError()
return
}
doSomething(email: email, phone: phone)
}
Now we are using return
inside if
to stop the execution of the function when the input is invalid. This way we maintain our code with just one indentation level, which is easy to read top to bottom.
Conclusion
The else
statement is a tool we have to write code but most of the time it is useless and you should avoid using it. We have other (and better) options.
Every time I write else
in my code I immediately ask myself: is it really necessary? And then most of the time I just refactor it to remove it.
Top comments (6)
I’m a big fan of that early return, allowing any future reader of your code to see quickly under what conditions it doesn’t need to do further work, and what the real work is.
Indeed, I think it is very easy to understand a function like that.
Sometimes I really miss dislike option
Please, can you explain why exactly?
I will be very happy to discuss it and learn new things with you too.
Hi,
Well there a no problem, programming with ELSE or without it.
In your opinion, it's better to write multiple IFs with multiple RETURNs without specifies the niche or some real use cases.
And in most of cases when I see an article, with title like "don't use XYZ" or "Avoid using XZY in programming", it's about somebody consider it's better or worst for readability.
Maybe on a real example, where are involved at least 3 engineers, to perform some experiments about how ELSE (or other statements) affects readability.
I agree that using hierarchy of IFs are not good, I mean:
IF 1=1 {
Something;
IF 1=2 {
Pass;
...
IF 100=100 {
return;
}
...
}
}
I see your point Ceban. When I was planning this article I was in trouble to bring examples to explain that concept and I agree that they can be better.
But I think that if a new developer reads this he/she can at least think about it and try to write better code day after day. In the end, my goal with this post is that.
Thank you very much for your time contributing here!