Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682

On 2018-10-02 20:14, Andrei Alexandrescu wrote:
> Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682

Swift has the "guard" statement to help with early returns (and unwrap optionals).

https://thatthinginswift.com/guard-statement-swift/
https://docs.swift.org/swift-book/ReferenceManual/Statements.html#ID524

-- 
/Jacob Carlborg

On 2018-10-02 21:09, Jacob Carlborg wrote:
> On 2018-10-02 20:14, Andrei Alexandrescu wrote:
>> Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682
> 
> Swift has the "guard" statement to help with early returns (and unwrap optionals).
> 
> https://thatthinginswift.com/guard-statement-swift/
> https://docs.swift.org/swift-book/ReferenceManual/Statements.html#ID524
> 

Is it:
For optional binding, Swift 2 has sugar for
if let !( ){}

Or am I missing the point of the guard statement?

On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu wrote:
> Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682

Thank you Andrei for mentioning this.  I always had this question of which one to choose - early return or nesting.

But the idea of 'early return' leads to multiple return statements too (for separate return conditions), right?

Certain people recommend that there be only one return statement (usually at the end) from a function.  The said advantage is that, in a maintenance code, if you later want to do something before returning, you can add it just above the return statement.  I have seen people enclosing the function logic inside a while(1) merely to stick on to single return at the end.

while(1)
{
	...
	break; //otherwise return would come here.
	...
	break;
}

return ...;


I (no expert) still don't have clear idea about the multiple return statements scattered inside a function.  So, I return where ever I want to return.  And, I use your C++ ScopeGuard to do that extra thing that is supposed to be done before returning ( from your article http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758 )

Any advices?

On Thursday, 4 October 2018 at 06:43:02 UTC, Gopan wrote:
> Certain people recommend that there be only one return statement (usually at the end) from a function.  The said advantage is that, in a maintenance code, if you later want to do something before returning, you can add it just above the return statement.
>  I have seen people enclosing the function logic inside a while(1) merely to stick on to single return at the end.
>
> while(1)
> {
> 	...
> 	break; //otherwise return would come here.
> 	...
> 	break;
> }
>
> return ...;

In terms of code maintenance, multiple break statements have no difference from multiple return statements. Those people are just trying to deceive themselves.

On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu wrote:
> Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682

Sean Parent covered early exits years ago in an excellent talk I just can't find anymore (maybe someone can point me to it?).
He nicely described how all that nesting builds up a huge context you need to keep in your brain while trying to reason about the function.

On Tuesday, 2 October 2018 at 20:53:40

> Is it:
> For optional binding, Swift 2 has sugar for
> if let !( ){}
>
> Or am I missing the point of the guard statement?

The variable declared in the guard statement is available after the statement. It’s like an if statement without the then part, only an else.

—
/Jacob Carlborg

On Thursday, 4 October 2018 at 06:43:02 UTC, Gopan wrote:

> Certain people recommend that there be only one return statement (usually at the end) from a function.  The said advantage is that, in a maintenance code, if you later want to do something before returning, you can add it just above the return statement.

D has the “scope” statement for this.

—
/Jacob Carlborg

On 10/02/2018 02:14 PM, Andrei Alexandrescu wrote:
> Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682

I was in college during the height of the Java craze, so my instructors highly recommended the deep nesting approach. This was because return statements are control-flow, and control-flow isn't very object-orientedy, and is old-fasioned and in the same category as the dreaded goto and was therefore bad. So I switched to the nesting-instead-of-returning style because it was "The Right Way".

Eventually, I realized the deep nesting approach meant the main core of my functions were carrying around extra context with them, thus decreasing my ability to read and reason about my code. By contrast, with early-returns, all of that special-case junk is taken care of and moved out of the way (much like catch blocks), so the main core of the function no longer had to be burdened by it. So I switched back to early-returns and learned to love them.

On 05/10/2018 8:23 AM, Nick Sabalausky (Abscissa) wrote:
> I was in college during the height of the Java craze, so my instructors highly recommended the deep nesting approach. This was because return statements are control-flow, and control-flow isn't very object-orientedy, and is old-fasioned and in the same category as the dreaded goto and was therefore bad. So I switched to the nesting-instead-of-returning style because it was "The Right Way".

"Terminology invoking "objects" and "oriented" in the modern sense of object-oriented programming made its first appearance at MIT in the late 1950s and early 1960s."[0].

And this is why you have to be very careful with any sort of trend in programming. Because it was already done before you were born (assuming you began learning after 1990) ;)

[0] https://en.wikipedia.org/wiki/Object-oriented_programming#History