In my experience, early returns usually reduce spaghetti and it is why I’m a huge fan of guard since it encourages this pattern. In an effort to return as early as possible, my conditions usually coalesce into small nuggets of logic that all terminate with a return which makes them really easy to identify and it seems to reduce the nesting depth of statements. When stepping through code in the debugger, it’s easy to spot a problem, too, if it hits a return I didn’t expect rather than weaving down a bunch of conditional code and maybe going into one branch, skipping over another, etc. all in an effort to reach the "one true return" at the end.
l8r Sean > On Dec 21, 2015, at 7:31 AM, Craig Cruden via swift-evolution > <[email protected]> wrote: > > The difference between issuing return embedded in multiple locations to > reduce verbosity is actually slightly more than extra verbosity it is > actually a different execution path. > > In my last example (Scalaish). The last and only expression in the function > is the whole match case - it terminates at the end of the function. > > def f2(input: Integer) : Integer = { > input match { > case _ if input > 10 => 10 > case _ if input < 0 => 0 > case _ => input > } > } > > Whereas if you sprinkle in returns as such, you are actually changing the > execution path: > > def f2(input: Integer) : Integer = { > input match { > case _ if input > 10 => return 10 <— function terminates here > case _ if input < 0 => return 0 <— function terminates and here > case _ => return input <— <— function terminates and here > } > } > > A move towards spaghetti like code. > > Now if you were to add an extra expression like using an intermediate value. > > def f2(input: Integer) : Integer = { > let x = input match { > case _ if input > 10 => 10 // no longer terminates here > case _ if input < 0 => 0 // no longer terminates here > case _ => input // no longer terminates here > } > x /2 // or return x/2 > } > > You would have had to go back and modify the original execution path with all > the embedded returns which can also be a source of unwanted defects if one is > missed (in larger functions). > > >> On 2015-12-21, at 3:29:27, Radosław Pietruszewski <[email protected]> wrote: >> >> I honestly don’t have a problem with having to say `return` inside >> functions. That’s not necessarily a -1, but I’m reluctant to say +1 when >> _even I_ don’t really have the problem with extra verbosity. >> >> *However*, as others pointed out, having to type `return` is a bit tiring in >> the context of a computer property’s “get”: >> >>> var twiceSomething: Int { self.something * 2 } >> >> — Radek >> >>> On 19 Dec 2015, at 14:30, Craig Cruden via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> When writing short functional code in a function it would be nice if the >>> return keyword were an optional keyword. >>> >>> Just return the last evaluated expression. >>> >>> >>> i.e. >>> >>> func flipFunc<T, U>(arg1: T, arg2: U) -> (U, T) { >>> (arg2, arg1) >>> } >>> >>> >>> The keyword return would still be there for breaking out of a function. >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
