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

521–530 of 601 posts

Re: Avoid Else, Return Early (2013)

#521

Post by okbake »

xg15 wrote: post #465
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 you move on from heavy OO to dicts/lists. Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them. I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and…

I'm a fan of TypeScript's structural typing for this reason. I can define an interface that describes the shape of a "plain old object" (it's fields and their types), and then write functions that accept/returns an object of that interface. What's great about structural typing is I don't have to explicitly say "create a new object of this type", any object that satisfies the shape of the interface is valid (object literals for example).

So you end up with the best of both worlds (in my opinion), where your state is made up of simple plain objects and you behaviors are just functions that accept simple plain objects, but you get all of the benefits of compile time static type checking because they are checked against the interface.

Re: Avoid Else, Return Early (2013)

#522

Post by tomn »

lisper wrote: post #279
alunchbox wrote: post #157

Earlier quoted context omitted.

python fans are going like "what are braces?"

The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to…

Enforces K&R style? I don't know what you mean...

    def foo(bar)\
    :
        if (bar > 5)\
        :
            return bar + 1;
        #
        else\
        :
            return bar - 1;
        #
    #

Re: Avoid Else, Return Early (2013)

#523

Post by monocasa »

jstimpfle wrote: post #518
monocasa wrote: post #486

Earlier quoted context omitted.

In general I agree with you, but that seems orthogonal to the subject at hand.

Parent's statement was that early returns are hard because you need to cleanup allocated resources. I don't think so, because there shouldn't (usually) be resources "on the stack".

But RAII is orthogonal to auto, static, or dynamic allocation.

Re: Avoid Else, Return Early (2013)

#524

Post by egypturnash »

RobertRoberts wrote: post #291
psyc wrote: post #197

Earlier quoted context omitted.

For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well as continue early in loops) and I cannot go back. The immensely reduced indentation is marvelous. Having that 'happy path' consolidated is more readable.

I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?

Habits based on what was fastest on slow machines where every cycle mattered and compilers weren’t as good at optimizing, I’d bet.

Re: Avoid Else, Return Early (2013)

#525

Post by lisper »

tomn wrote: post #522
lisper wrote: post #279

Earlier quoted context omitted.

The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to…

Enforces K&R style? I don't know what you mean... def foo(bar)\ : if (bar > 5)\ : return bar + 1; # else\ : return bar - 1; # #

I'm not sure whether to laugh or cry

Re: Avoid Else, Return Early (2013)

#526

Post by anonytrary »

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…

You guys just made me feel better about myself! Thanks, HackerNews.

Re: Avoid Else, Return Early (2013)

#527

Post by eecks »

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…

I've never thought about this before but I nodded with agreement with each point.

Re: Avoid Else, Return Early (2013)

#528

Post by aiham »

crooked-v wrote: post #453
Kapow wrote: post #420

Earlier quoted context omitted.

That's just a ternary operator. I use that in Java all the time. value = boolean ? this_value : other_value; If the branching logic gets too complicated, I usually move it into a function (private method) with a return in each branch.

And in Javascript, once do-expressions go from a proposal to a common part of the language, this will be a thing: let value = do {if (boolean) { this_value } else { other_value }} ...which is even closer to the Elixir style than JS's ternary operator (which is identical to Java's).

What's the advantage over JS's ternary operator?

Re: Avoid Else, Return Early (2013)

#529

Post by mrlyc »

koolba wrote: post #95
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 you get joy deleting large swaths of code. This is the true sign of a programmer's transcendence. Specifically the irrational joy of seeing net negative LOC diffs. It's not about how much you can add. It's about how much you can remove without sacrificing correctness, functionality, and readability.

Sometimes deleting code isn't enough and you have to do a rewrite. I once rewrote 2,650 lines of C as a seven line shell script. The previous programming team had written a data transfer program with its own implementation of ftp. I just used the one that was already on the computer.

Re: Avoid Else, Return Early (2013)

#530

Post by codehalo »

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…

All good arguments except for the end braces/LOC one. The visual cue is worth far more than the one line it takes up.
Post reply on HN