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

91–100 of 601 posts

Re: Avoid Else, Return Early (2013)

#91

Post by jrimbault »

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...

Re: Avoid Else, Return Early (2013)

#92

Post by arghwhat »

Waterluvian wrote: post #51
Cthulhu_ wrote: post #6

A more formal name for this approach is / could be Guard Clauses: https://refactoring.com/catalog/replaceNestedConditionalWith... . This pattern has been elevated to a language construct in Swift: https://thatthinginswift.com/guard-statement-swift/

JavaScript has the guard operator. It can really clean up your control flow when you know it's a guard operator and not just logical AND.

Logical AND in JavaScript can be used as a guard, by why in the world would you think of it as anything other than a logical AND?

If you start thinking it is a "guard operator", I would think that going down the wrong path, which might promote misunderstanding of the behavior.

Re: Avoid Else, Return Early (2013)

#94

Post by menacingly »

At some point in the last few years, I shifted into doing this, but I've just recently been trying to decide if it's a good idea. Every once in a while I lean into some cute little expedience that later annoys me when I'm digging in old code.

Re: Avoid Else, Return Early (2013)

#95

Post by koolba »

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.

Re: Avoid Else, Return Early (2013)

#96

Post by arghwhat »

thesimon wrote: post #12

Sort of agree, but I don't think if (err) { handleError(err) return } and if (err) return handleError(err) are equally good. The second one doesn't really make it clear wether handleError returns a value and that value is intended to be returned.

I don't think the latter is legal in most (non-JS) languages if the return value of the outer function is void.

Even if it is, I definitely agree that it should only be done if you want to communicate that handleError's return value is meaningful and should bubble up.

Re: Avoid Else, Return Early (2013)

#98

Post by randomerr »

olavk wrote: post #58
Hendrikto wrote: post #50

Earlier quoted context omitted.

You could still write it as fun max(a, b) { if a > b { return a } return b } Not saying this is necessarily better or worse. The point I want to make is that your case isn’t special.

I am arguing this is worse, since it expresses the logic in a more convoluted way.

I guess I would politely argue that creating new functions would make reading code harder in basic example such are this. You'll be jumping all round or possibly separate files. Obviously larger logic tress should be pruned. Side note: a lambda function may get around this specific instance.

Re: Avoid Else, Return Early (2013)

#99

Post by anyzen »

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 comments are extra weight that should only be in public or algorithm/need to know areas.

This! Comments should convey programmer's intention and explain the thought process, not the code itself. Also, too many comments usually indicate that code should be refactored.

Re: Avoid Else, Return Early (2013)

#100

Post by sk5t »

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…

Oh sweet summer child. This list reflects but one possible course of programmer evolution. Some languages--and I'm thinking particularly of scala--encourage one-liners. Comments are rarely extra weight if there's anything worth explaining; access modifiers are not of the essence here. Collection types are no replacement for OO patterns that have a reason to exist in the first place. There's a good argument to be made that early exits, other than perhaps constraint checking, make control flow harder to reason about.
Post reply on HN