5 ms·

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 a

• kieckerjan 8y ago
  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.)
• hliyan 8y ago
  Seconded. http://wiki.c2.com/?GuardClause http://wiki.c2.com/?GuardClause
• Someone1234 8y ago
  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.
  • deleted 8y ago
    [deleted]
• projektfu 8y ago
  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.
• arithma 8y ago
  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
• userbinator 8y ago
  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(); }
  • 8note 8y ago
    promise chains do that pretty nicely Promise.start() .then(doOnething) .then(doSecondThing) .then(doThirdThing) .then(doLastThing) .catch(handlesomeerrors)
    • coldtea 8y ago
      That's because promises kind of Monad-ic.
  • s4vi0r 8y ago
    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.
• mhd 8y ago
  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.