Is it better to wrap code into an 'IF' statement, or is it better to 'short circuit' the function and return?

Question

I'm doing some coding in JavaScript, and I am having a lot of instances where I have to check some stuff before I proceed. I got into the habit of returning early in the function, but I'm not sure if I am doing this right. I am not sure if it have an impact on the complexity of my code as it grows.

I want to know from more experienced JavaScript coders, what is a better general practice out of the following two examples. Or is it irrelevant, and they are both OK ways of writing this particular IF block?

1) Returning Early or "Short Circuit" as I call it (Guard Clause).

ServeAlcohol = function(age)
{
     if(age < 19)
         return;


     //...Code here for serving alcohol.....
}

..Or...

2) Wrap code into an IF statement.

ServeAlcohol = function(age)
{
     if(age >= 19)
     {
          //...Code here for serving alcohol.....
     }
}

Answer 1

Hello,

I prefer the first one, because it's a guard condition and you exit directly. But I don't think there is performance issues with either, just that it's your preference... Both will return execution directly...

Answer 2

Personal choice. For me, if there are some "stop" conditions I can check at the beginning of the method, I prefer using the "return" pattern. But only if I can do them all in the beginning of the method.

Answer 3

Usually I have input-validation return right away. Imaging if you had a bunch of conditionals, you get a mess of nested ifs right away.

Generally once I get past input validation I avoid multiple returns, but for validation I return right away. Keeps it cleaner IMHO.

Answer 4

It really depends. I do like one point of return for simple functions, but anything longer than 10-20 lines and I'll start breaking things up for the sake of code clarity.

Answer 5

I prefer the first one, because it's the process of elimination, where you return out of the function before the program even has to step through the next round of logic. I call it my prereq check - where the function won't execute if it doesn't meet the prereq check

In fact, I do this all the time, for example, the classic one is where i have a function that's expecting an integer and i get a string, i check at the top of the function if it's an integer, NOT if it's not a string or not another object/type, that's just stupid in my book.

It's like a college application to Harvard, a prerequisite:

'I don't want to even want you to come for an interview if you don't have a 3.5GPA or higher!'

:=)

Answer 6

FWIW, I'll offer a contrary opinion. Structured Programming suggests that a function should have one point of exit. I think there are some compiler optimizations that are not available if you use early returns, break statements, goto statements and the like. Also more branches in your code means its harder to fill the CPU pipeline resulting in a possible performance reduction... There are also reasons for not returning early that deal with rigorous (i.e. algebreic) reasoning about correctness.

Structured Programming wiki article

Answer 7

The first one is usually preferred simply because it reduces the needed indentation (which could get way out of hand). There is no real performance difference.

Answer 8

In my opinion, as a best practice, I think it is more important to consistently use braces with your control blocks, even if their body is only one line.

Consistent

if ( condition ) {
    statement;
    statement;
}

if ( condition ) {
    statement;
}

Not consistent

if ( condition ) {
    statement;
    statement;
}

if ( condition )
    statement;

But even still, this is completely subjective.

As for when to break out of a function, and levels of indentation, that's subjective too. Research and experience have shown that exiting a function at only one point (the end) is easier to debug, optimize, etc. On the other hand, multiple levels of indentation can make a function difficult to read.

Answer 9

There are some people who think that each function should have a single exit point. However, I find it clearer when quick conditional checks like the one you mentioned are done at the beginning. It also avoid some code from being unnecessarily run.

Answer 10

A general rule I've heard is basically fail early and fail often. You never know when a single line of code is pointing to some super-overloaded setter that's working way harder than you might think. If you can prevent that line of code from being executed - say, by returning early - then your code is going to be exponentially more efficient.

In other words, if you can return early and keep code from executing, do it at every turn - especially if you are concerned at all about performance. This might not be as important in something like JS, I suppose - I'm more of an AS3 guy - but the same logic applies.

If you have a lot of cases, it might be best also to trace out the point of failure in each one - in your example, trace out that this returned early because the age was too low. That'll help other developers who go in and attempt to debug your code, they'll know where things fail and why.

Hope that helps! :)

Answer 11

Alternatively, since JavaScript is scheme in disguise

HandleRequestForAlcohol = function(age) { 
    ( IsUnderAge(age) ? RespondUnderAge : ServeAlcohol )();
}

The idiom for selecting the function isn't that important, rather that if you are doing complex validation and then have multiple processes, factor these to separate functions rather than making one big one, unless it's in a very performance critical bit of code.

Answer 12

If there are multiple / complex guards, I would use the return. Otherwise in the case of one simple condition (in a smallish function) then I prefer using an if.