Hacker News Reader

Comment by Kaveren | Hacker News Reader

I vehemently disagree with the idea that returning from a function often is bad and that it should be used "sparingly". I find that code that returns as early as possible is the best. The idea of a nearly mandatory single return point is a very antiquated notion. I'm much more concerned when I see ten levels of indentation for no good reason.

Likewise with continue and break. I think this advice is very bad. All the other recommendations seemed fine.

View on HN

Second that. I disagree with the premise that such code is hard to understand. On the contrary: when done well, early returns pop your mental stack and free up mental resources when reading code. (I guess I am a bit extreme. I even advocate judicious use of goto's in C code, for instance for cleaning up state after an error or for writing out FSM's without the distracting fluff of loops and switches.)

Returning multiple times can also reduce nesting, since you can add guard-like statements and return early.

Take this contrived example:

     function foo(bar)   
     {     
          var result, error;    
 
          if(bar is null) 
          {    
                error = "{NameOf(bar)} is required";    
                result = null; 
          }    
          if(bar is not null)
          {
                 ... Main function logic ...    
          }   
          return Tuple(result, error); 
     }

If you can return multiple times instead you'd be able to write:

     function foo(bar)   
     {     
          var result, error;    
 
          if(bar is null) 
          {    
             return Tuple(null, "{NameOf(bar)} is required");  
          } 
    
          ... Main function logic ...     

          return Tuple(result, error); 
     }

Assume "Main function logic" has several of nest of its own (branching, loops, etc) it quickly gets difficult to read.

In the days of Pascal, where multiple returns didn't exist, I used to write a nested function that expected sanitized inputs and the outer function had the input checking logic.

Seconded. http://wiki.c2.com/?GuardClause

When I can't return early, I find that the && operator, because of its short-circuit evaluation, is extremely useful for writing chains of "everything before must successfully execute" without the labourious series of "if/else ladders" or deep nesting that would otherwise be needed. Compare:

    success = doOneThing() 
           && doSecondThing()
           && doThirdThing()
           ...
           && doLastThing();

and the more common "traditional" way:

    success = doOneThing();
    if(success)
    {
        success = doSecondThing();
    }
    if(success)
    {
        success = doThirdThing();
    }
    ...
    if(success)
    {
        success = doLastThing();
    }

promise chains do that pretty nicely

    Promise.start()
    .then(doOnething)
    .then(doSecondThing)
    .then(doThirdThing)
    .then(doLastThing)
    .catch(handlesomeerrors)

That's because promises kind of Monad-ic.

What you want is a monad.

Instead of loading up every language with stupid keywords that are meant to simplify monadic code (but only for one domain), language designers should really take a page out of Haskell or Scala's book and think seriously about unifying on a do notation/for comprehension type construct.

That way regardless of if you're working with promises or not, you don't have to worry about hacking it with && or nesting 10 layers deep with if/else.

If your functions are short enough and with a low level of cyclomatic complexity, it really shouldn't matter all that much. If it means that you have to wrap 2/3rds of your function in an if just so that the single final return still works and that if then contains 20+ lines, then try to correct that in the first place.

Having said that, I'm with the "guard statements" crowd, too, but it would probably be better if that were handled by other parts of the language syntax. Contracts, for example.

The best light I saw this recommendation is: apart from guard statements at the top of a function which have return's, the advice should hold

Reply on news.ycombinator.com