I have recently watched several videos and read many posts about the misuse of 'else' and why we should avoid it. At first I thought 'well, it will be the
novelty and they will forget about this in a few months'. To my surprise it is not like that, and they have been dealing with this subject for a long time.
One can say 'and why would I stop using' else 'if they are indispensable in any program', and you are absolutely right, I thought the same thing until I think I have come to understand it. I am going to put an example; Let's say we have to do three checks when registering a user and each of these checks has an exception attached if it is not true:
- Check that the username follows a correct format.
- Check if the user is already registered.
- Check that the user has a correct image
It is not a real case but it can help us. Ok, to do these checks we would have to do the following
Seems like everything is ok right? Or not? Leaving aside the three levels of indentation, it could be a valid solution. The problem is that if we have a lot of code within each check, when we get to the 'else' we won't even remember what we're checking. What not using 'else' proposes is to put it in a different way, something like this:
Doing it this way, we would check from the first moment if we can go ahead with the registration, and then do the logic if everything goes well. Without a doubt, in the second way everything seems to be more organized and clear when reading code.
Top comments (11)
I generally follow a similar pattern, which is also known as 'early return' and nicely explained here by Szymon: szymonkrajewski.pl/why-should-you-...
What matters to me is that there is a common pattern to functions across a codebase, so the reader (hello you in 15 months time) can see the 'happy path' easily, and can see the priority of unhappy conditions, which communicates what matters more too.
Use of assertions or guard conditions also results in a similar pattern for good reason :)
I once argued AGAINST early return, but then I tried it and I can't imagine why I didn't use it before.
Early on in my career (a long time ago in a galaxy far far away and all that) I had been taught a rule that a function should only ever have one return in order to make it clear what was being returned, and I clung to that rule for too long.
It's one of the best changes I've made to my code style in years. I love it.
I was taught exactly the same thing, but when you adhere to that you end up with massive blocks. Early return is king!
I've been using this method for years now and can definitely say it makes code far more legible and concise. If/else has it's place at times, but I really think (and hope) that early returns should be taught as a standard practice.
I wouldn’t religiously avoid
elsejust because some people abuse it. That would make a lot of code significantly less expressive and result in unnecessary branch condition evaluations. A simple if-else, without else, would have two ifs evaluating the same expression, with the 2nd expression negated.The early return pattern helps you to write clean, performant code. And your example is ideal. However, there are of course cases where else is the best solution, so your title threw me off a little.
Agree with you, maybe I should add "sometimes" 😅
I also prefer to fail fast. So i do this checks in a function and return at first failed checked. So no else.
Anyway, else is not evil and can be very clear to force programmer mind to understand that two condition are not mutually exclusive. It helps months ago I wrote something
early return is good - but as a nitpicky thing, verification stuff should be done together so you can inform the user of all the errors at once, rather than hitting them with a stick, one error at a time....
This particular example is misuse of else, there can be general cases that you need to cover with the else that would not need separate if statements.
In short, making general statements that else should be avoided is incorrect. It depends largely on context
I use the else keyword most time, I'll take note tho