Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid Else, Return Early (2013)

blog.timoxley.com

Post reply on HN
Print view View original

221–230 of 601 posts

Re: Avoid Else, Return Early (2013)

#221

Post by recursive »

weinzierl wrote: post #200
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…

I have doubts about whether "real" projects generally have these kinds of concerns. But even if they do, you can clean them up in a `finally`, or your language's equivalent.

Re: Avoid Else, Return Early (2013)

#222

Post by zarex »

Aaargh20318 wrote: post #177
fouc wrote: post #119

Earlier quoted context omitted.

Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.

> Only "brilliant" code ends up needing comments. Code shows what is being done. Comments should explain why it's being done.

That's a really nice approach. Thanks for sharing, I might borrow it sometime!

Re: Avoid Else, Return Early (2013)

#223

Post by drawkbox »

weinzierl wrote: post #200
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…

> starts to depend on the kind of resource to manage.

Exactly, simple but not too simple. If the condition does not need to return early or can't, you don't.

> quickly end up managing file descriptors, sockets, handles, GUI resources

In some of the cases you describe you wouldn't return early or depending on the need, but if you can you should to minimize work.

Some examples: file descriptors you'd return early if the file does not exist, sockets you'd return if dropped or compromised and you have performed cleanup, handles if null, gui resources can be lots of things but if you were doing something where you needed to cleanup you can cleanup and return. In C# for instance you might wrap some of that in a using such as files, sockets, streams etc. Most of your examples you might already be in the meat of the return early flow and usually there is still a return at the very end but in/after the meat.

Returning early isn't saying do a dirty break or asserting out, you don't return early before cleaning up if you are within some resource.

Re: Avoid Else, Return Early (2013)

#224

Post by defertoreptar »

jrimbault wrote: post #91
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with Allman. That makes a difference at least in my case.

Re: Avoid Else, Return Early (2013)

#225

Post by melling »

Merad wrote: post #106
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.

The One True Brace Style:

https://softwareengineering.stackexchange.com/questions/9954...

The name tells you that it won.

Re: Avoid Else, Return Early (2013)

#226

Post by ryandrake »

One drawback of returning early is it can complicate debugging. If I want to stop on a breakpoint when a function exits, it's nice to be able to set a single breakpoint on the final return statement. When you spew returns all over the function, your life gets more complicated. Some debuggers let you put the breakpoint on the final brace and will do the right thing, others make you find and put a breakpoint on each return.

Another thing I avoid doing because it complicates debugging is putting a final calculation on the same line as the return:

    return combine(foo.calculate(), bar.calculate());
Some debuggers make it difficult for me to examine the result of the combine() function and/or the results of the .calculate() methods. Better to be explicit:

    auto foo_result(foo.calculate());
    auto bar_result(bar.calculate());
    auto combine_result(combine(foo_result, bar_result);
    return combine_result;
There, much better, arguably more readable, and I can stop at whatever step I need to.

I've had to debug far more code in my career than I've had to write, which has encouraged practices that make debugging as straightforward as possible.

Re: Avoid Else, Return Early (2013)

#228

Post by JoeAltmaier »

melling wrote: post #225
Merad wrote: post #106

Earlier quoted context omitted.

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.

The One True Brace Style: https://softwareengineering.stackexchange.com/questions/9954... The name tells you that it won.

That link's favorite response actually refutes that brace style matters at all. No correlation with bug frequency detectable. So its all religion.

Re: Avoid Else, Return Early (2013)

#229

Post by bottled_poe »

3pt14159 wrote: post #217
weinzierl wrote: post #200

Earlier quoted context omitted.

> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…

Oh common. This might be true for a very specific type of codebase, but it isn't true for programming in general. If I'm coding a library of standard statistical functions I'm exiting early. If I'm coding a Rails webapp I'm exiting early. If I'm coding a shell script, even one used on tens of thousands of servers, I'm exiting early. The resource almost all programmers are managing is the resource of human time. Human…

I guess I would agree with the concept of managing “human time”, but I believe you are focusing on the wrong human. The developer will certainly spend a lot of time writing and maintaining a code base, but that’s minuscule compared to the time spent by the end user. What software design principles will save the user the most “human time”?

Re: Avoid Else, Return Early (2013)

#230

Post by lkjalskdjflkasd »

vortico wrote: post #191
tzahola wrote: post #87

Earlier quoted context omitted.

You're turning RAII upside down... Learn to use proper RAII and you won't need this defer hack.

Tell that to the APIs I work with, like POSIX sockets/Winsock, etc. You're suggesting that I wrap them all with RAII? That's ridiculous when you have hundreds of C types which are all used just once or twice. Using defer makes elegant/simple C-like code because it uses the C APIs directly and is nearly the same number of lines of code as a C programmer would write without using defer. I fail to see how "learning prop…

I can tell by your example you don't know idiomatic C++, keep it mind it takes years to get to that point.

Consider using noexcept or just use C.

Post reply on HN