[ACCEPTED]-Is returning early from a function more elegant than an if statement?-return

In most cases, returning early reduces the 5 complexity and makes the code more readable.

It's 4 also one of the techniques applied in Spartan programming:

Minimal use of Control

1. Minimizing the use of conditionals by using specialized constructs such ternarization, inheritance, and classes such as Class Defaults, Class Once and Class Separator
2. Simplifying conditionals with early return.
3. Minimizing the use of looping constructs, by using action applicator classes such as Class Separate and Class FileSystemVisitor.
4. Simplifying logic of iteration with early exits (via return, continue and break statements).

In 3 your example, I would choose option 2, as 2 it makes the code more readable. I use the 1 same technique when checking function parameters.

This is one of those cases where it's ok 32 to break the rules (i.e. best practices). In 31 general you want to have as few return points 30 in a function as possible. The practical 29 reason for this is that it simplifies your 28 reading of the code, since you can just 27 always assume that each and every function 26 will take its arguments, do its logic, and 25 return its result. Putting in extra returns 24 for various cases tends to complicate the 23 logic and increase the amount of time necessary 22 to read and fully grok the code. Once your 21 code reaches the maintenance stage then 20 multiple returns can have a huge impact 19 on the productivity of new programmers as 18 they try to decipher the logic (its especially 17 bad when comments are sparse and the code 16 unclear). The problem grows exponentially 15 with respect to the length of the function.

So 14 then why in this case does everyone prefer 13 option 2? It's because you're are setting 12 up a contract that the function enforces 11 through validating incoming data, or other 10 invariants that might need to be checked. The 9 prettiest syntax for constructing the validation 8 is the check each condition, returning immediately 7 if the condition fails validity. That way 6 you don't have to maintain some kind of 5 isValid boolean through all of your checks.

To 4 sum things up: we're really looking at how 3 to write validation code and not general 2 logic; option 2 is better for validation 1 code.

As long as the early returns are organized 20 as a block at the top of the function/method 19 body, then I think they're much more readable 18 than adding another layer of nesting.

I try 17 to avoid early returns in the middle of 16 the body. Sometimes they're the best way, but 15 most of the time I think they complicate.

Also, as 14 a general rule I try to minimize nesting 13 control structures. Obviously you can take 12 this one too far, so you have to use some 11 discretion. Converting nested if's to a 10 single switch/case is much clearer to me, even 9 if the predicates repeat some sub-expressions 8 (and assuming this isn't a performance critical 7 loop in a language too dumb to do subexpression 6 elimination). Particularly I dislike the 5 combination of nested ifs in long function/method 4 bodies, since if you jump into the middle 3 of the code for some reason you end up scrolling 2 up and down to mentally reconstruct the 1 context of a given line.

In my experience, the issue with using early 17 returns in a project is that if others on 16 the project aren't used to them, they won't 15 look for them. So early returns or not - if 14 there are multiple programmers involved, make 13 sure everyone's at least aware of their 12 presence.

I personally write code to return 11 as soon as it can, as delaying a return 10 often introduces extra complexity eg trying 9 to safely exit a bunch of nested loops and 8 conditions.

So when I look at an unfamiliar 7 function, the very first thing I do is look 6 for all the returns. What really helps there is 5 to set up your syntax colouring to give 4 return a different colour from anything else. (I 3 go for red.) That way, the returns become a useful 2 tool for determining what the function does, rather 1 than hidden stumbling blocks for the unwary.

Ah the guardian.

Imho, yes - the logic of 5 it is clearer because the return is explicit 4 and right next to the condition, and it 3 can be nicely grouped with similar structures. This 2 is even more applicable where "return" is 1 replaced with "throw new Exception".

As said before, early return is more readable, specially 14 if the body of a function is long, you may 13 find that deleting a } by mistake in a 3 12 page function (wich in itself is not very 11 elegant) and trying to compile it can take 10 several minutes of non-automatable debugging.

It 9 also makes the code more declarative, because 8 that's the way you would describe it to 7 another human, so probably a developer is 6 close enough to one to understand it.

If 5 the complexity of the function increases 4 later, and you have good tests, you can 3 simply wrap each alternative in a new function, and 2 call them in case branches, that way you 1 mantain the declarative style.

In this case (one test, no else clause) I 6 like the test-and-return. It makes it clear 5 that in that case, there's nothing to do, without 4 having to read the rest of the function.

However, this 3 is splitting the finest of hairs. I'm sure 2 you must have bigger issues to worry about 1 :)

option 2 is more readable, but the manageability 5 of the code fails when a else may be required 4 to be added.

So if you are sure, there is 3 no else go for option 2, but if there could 2 be scope for an else condition then i would 1 prefer option 1

Option 1 is better, because you should have 4 a minimal number of return points in procedure. There 3 are exceptions like

  if (a) {
    return x;
  }
  return y;

because of the way a 2 language works, but in general it's better 1 to have as few exit points as it is feasible.

I prefer to avoid an immediate return at 13 the beginning of a function, and whenever 12 possible put the qualifying logic to prevent 11 entry to the method prior to it being called. Of 10 course, this varies depending on the purpose 9 of the method.

However, I do not mind returning 8 in the middle of the method, provided the 7 method is short and readable. In the event 6 that the method is large, in my opinion, it 5 is already not very readable, so it will 4 either be refactored into multiple functions 3 with inline returns, or I will explicitly 2 break from the control structure with a 1 single return at the end.

I am tempted to close it as exact duplicate, as 5 I saw some similar threads already, including 4 Invert “if” statement to reduce nesting which has good answers.

I will let it live 3 for now... ^_^

To make that an answer, I 2 am a believer that early return as guard 1 clause is better than deeply nested ifs.

I have seen both types of codes and I prefer 4 first one as it is looks easily readable 3 and understandable for me but I have read 2 many places that early exist is the better 1 way to go.

There's at least one other alternative. Separate 8 the details of the actual work from the 7 decision about whether to perform the work. Something 6 like the following:

public function setHitZone(target:DisplayObject):void
    {
        if(_hitZone != target)
            setHitZoneUnconditionally(target);

    }

public function setHitZoneUnconditionally(target:DisplayObject):void
    {
        _hitZone.removeEventListener(MouseEvent.ROLL_OVER, onBtOver);
        _hitZone.removeEventListener(MouseEvent.ROLL_OUT, onBtOut);
        _hitZone.removeEventListener(MouseEvent.MOUSE_DOWN, onBtDown);

        _hitZone = target;

        _hitZone.addEventListener(MouseEvent.ROLL_OVER, onBtOver, false, 0, true);
        _hitZone.addEventListener(MouseEvent.ROLL_OUT, onBtOut, false, 0, true);
        _hitZone.addEventListener(MouseEvent.MOUSE_DOWN, onBtDown, false, 0, true);

    }

Any of these three (your 5 two plus the third above) are reasonable 4 for cases as small as this. However, it 3 would be A Bad Thing to have a function 2 hundreds of lines long with multiple "bail-out 1 points" sprinkled throughout.

I've had this debate with my own code over 13 the years. I started life favoring one return 12 and slowly have lapsed.

In this case, I prefer 11 option 2 (one return) simply because we're 10 only talking about 7 lines of code wrapped 9 by an if() with no other complexity. It's 8 far more readable and function-like. It 7 flows top to bottom. You know you start 6 at the top and end at the bottom.

That being 5 said, as others have said, if there were 4 more guards at the beginning or more complexity 3 or if the function grows, then I would prefer 2 option 1: return immediately at the beginning 1 for a simple validation.