Why You Should Drop The 'Else' Keyword When Writing Conditionals

There's one thing I would like to showcase on that example:

function canDrinkAlcohol($age)
{
    if ($age == "") {
        echo "You must provide your age.";
        return;
    }
    if ($age < 18) {
        echo "Sorry, alcohol is not for you.";
        return;
    }
    echo "You are free to drink alcohol.";
    return;
}

What's the intent of the function canDrinkAlcohol?

If you ask me I'd say to discern whether a User can or cannot drink alcohol based on their age.

If you send the age directly to this function (and not a User instance or any other data structure), why ensuring here that age is set?

const canDrinkAlcohol = (age: number) => age > 18 ? true : false;

Note that we are using "if - else" in this example, just that it's in a shape of a ternary, while keeping it much more understandable, the function has single responsibility and I don't think I could stress it more than what I already did :D

The equivalent in PHP would be:

function canDrinkAlcohol($age) {
    return ($age > 18) ? true : false;
}

Logic on this is that this function should not validate that the user provided the age, this function returns "can drink alcohol if age is X?", and the answer is "if you're over 18 then sure! in any other case (including the case in which you don't tell me your age) NOPE".

It is now easily testable and reusable and can be properly used like that:

function main() {
    $age = $_POST['age']; // or whatever source you wish to use
    if (!$age) {
        echo "You must provide your age.";
        return;
    }

    echo (canDrinkAlcohol($age)) ? "You are free to drink alcohol." : "Sorry, alcohol is not for you.";
     /* 
        other stuff 
    */
}

Cheers!

Returning early from functions via guard clauses is definitely a valuable technique, but I don’t think the problem with your example here is the ‘else’ clause. The example in your post illustrates a more general concern about readability of nested conditionals.

There’s nothing inherently wrong or bad about an else clause, and it could well be argued that being explicit with else aids readability by making the developer’s intent clear.

A well placed switch statement, by the way, can also be a thing of beauty.

The problem with early returns is that they create implicit else-branches that aren't easily spotted:

local function doathing()
  doanotherthing()
   if condition then
      return "Early Return"
   end
   return domorethings()
end

In this example, domorethings() looks like an unconditional part of the function that runs after some conditional code. You have to look at the code above to spot the early return, which takes more effort.

Meanwhile, an example using else:

local function doathing()
  doanotherthing()
   if condition then
      return "Early Return"
   else
      return domorethings()
   end
end

This code does the same thing, but it's immediately apparent that domorethings() is inside a conditional block, and may not run. Just from looking at the indentation we can tell the structure of this function: It starts doing some stuff, then splits into two branches.

This makes the code a lot easier to scan and to reason about, which is why else and else-if constructs are a thing in almost every programming language. Trying to simulate else with early returns is like simulating if with goto and claiming it helps with readability.

Thanks so much for sharing!

I really like your comment on how unnecessary else blocking introduces nonlinearity into your code. I thought I was writing clean code prior but leveraging better if placement has been a huge improvement for me over the last year or so

On top of limiting my use of else blocks I've also found (mostly) eliminating loops and opting for filter, map, and reduce operations instead has also been a huge improvement - I didn't realize how much of an implicit spaghetti-mess loops can be compared to their more explicit functional counterparts

Small improvements like this build up into some really elegant code - thanks again for sharing! :D

Good post and I agree with else usually being unnecessary. The broader concept at play here is simply FLATTENING your logic. Any time you see code blocks that have multiple layers of nesting, there are usually opportunities to "flatten" the logic by removing the nesting.

Another concept that you're hitting here is that the return statement gives us a chance to "short-circuit" the logic in a function - which also has the benefit of flattening the logic.

I too started out using lots of elses. Returning instead of using else is something that I learned after using ReSharper (with C#) for a while.

Another benefit is that there is less indentation for the remainder of the code.

I would add one thing though. In my experience, I've found that using multiple return guard statements near the top of a function is ok. I would suggest caution with returning in the middle of more complex functions though. It's very easy to miss a code-path when in the midst of lots of logic, and get an unexpected result.

In short: using guard statements is good - it tidies up the code, and reduces nesting; use caution when returning early in the middle of a complex function.

For good practice, a boolean should be returned whenever a function starts with an inquiring verb like can, is, has, etc. The result can then be as simple as a checkand the validation can be handled via type hinting:

function canDrinkAlcohol(int $age): bool
{
    return $age >= 18;
}

One thing I noticed after only using "if" is the proper use of "return".