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

131–140 of 601 posts

Re: Avoid Else, Return Early (2013)

#131

Post by wildmusings »

SideburnsOfDoom wrote: post #43
wildmusings wrote: post #35

Earlier quoted context omitted.

Goto is heavily used to return early, by jumping to the cleanup section at the bottom of the function. Otherwise, you have to repeat the cleanup code at each exit point, or use the dreaded pyramid of doom where each failure point introduces another indent level, which is what the author here is trying to avoid in the first place.

"cleanup section at the bottom of the function" is pretty rare in JavaScript, which is what the original blog post is discussing. Same with Java, C#, Ruby etc. No, it doesn't play well with early return, so avoid mixing them.

I should have specified that I was talking about C. You usually don’t need this pattern when you have garbage collection or C++ RAII.

Re: Avoid Else, Return Early (2013)

#132

Post by allyjweir »

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.

"The only good diff is a red diff"

Re: Avoid Else, Return Early (2013)

#133

Post by kstenerud »

euroclydon wrote: post #13

If you have a complicated function, and several exit points where you want to bail out, they why not just put a "label: bail" and goto it? GOTO has a bad rap IMO. There's a place for it, and the author should probably be using it.

Because if you don't have resource cleanup to do in the method, the GOTO boilerplate is just making things unnecessarily more complicated than a simple return.

Re: Avoid Else, Return Early (2013)

#134

Post by vanderZwan »

fouc wrote: post #119
optimuspaul wrote: post #108

Earlier quoted context omitted.

> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.

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.

There is a ton of code that only exists because of issues elsewhere in the code. This is the opposite of brilliant code: these are the dirty patchworks, the hacks glueing the whole thing together. Yet often these hacks are necessary, at least until some bug is fixed elsewhere.

Clear, self-documenting code is great but it can't capture that holistic insight into what the whole program is doing. It can't capture context, because the whole point of clean refactored code is to be as context-free as possible.

Re: Avoid Else, Return Early (2013)

#135

Post by vinceguidry »

brazzledazzle wrote: post #121
vinceguidry wrote: post #52

In Ruby these are idiomatic enough to have a name and are built into the linter, so it'll yell at you if it sees that you're not using guard clauses. As a further refinement, I will often take tricky conditional logic and put them into a method that consists of nothing but guard clauses and a return true or false at the bottom of the method. In Ruby you can use ? and ! at the end of method names, so I'll give the met…

I would love Ruby-style guard clauses in JavaScript. Sometimes I wish I’d never written anything in Ruby just so I’d stop thinking about how great it would be if other languages shared some of its features.

I moved to Hyperloop on my personal projects. Give it a shot, I think you might like it.

http://ruby-hyperloop.org/

The guys in Gitter chat are quite helpful if you get stuck.

Re: Avoid Else, Return Early (2013)

#136

Post by Mithaldu »

titzer wrote: post #125
Mithaldu wrote: post #115

Earlier quoted context omitted.

Comments are not documentation. Documentation explains HOW to use a thing. Good comments explain WHY a thing is strange. Bad comments explain WHAT a thing does and must be made redundant by extracting and naming the thing.

> Comments are not documentation. Probably overly generalized to be pithy, but no. Comments are by very definition documentation, which can and should cover of all of the what/why/who/how/where. Documentation that occasionally explains how to use code can actually be useful! Unless you actually get around to writing a user manual (which gets out of date), please do consider documenting how something should be used, p…

As a Perl developer i mean this literally and transfer it to other languages as well. POD (or a block comment above a function) describes the API and use cases of the function. Inline comments inside the function exist only to provide explanation for the next maintainer when they see a strange construct. Any other type of comment needs to be refactored.

Also, i never said documentation isn't useful. HOW and WHY are useful. WHAT in documentation and comments isn't because it should be in the variable/function/method/class/instance name.

(Who/Where/When are covered by the source repository and the blame function.)

Re: Avoid Else, Return Early (2013)

#137

Post by [deleted] »

fyi1183 wrote: post #117
jrimbault wrote: post #91

Earlier quoted context omitted.

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

Oh but it is, independent of the language. Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, which makes it easier to maintain.

[deleted]

Re: Avoid Else, Return Early (2013)

#138

Post by wiz21c »

davewritescode wrote: post #37
wiz21c wrote: post #5

I would agree. Putting "early out" logic at the beginning allows the one who reads the code to lower the cognitive load a bit. Basically "I know I can read the following code safely because the error handling and parameter sanitizing is done". But that only works with mundane operations (error handling, parameters sanitizing). If the operations convey some important semantics, then I prefer to see the guarded code in…

Big blocks of if/else logic impose a heavy cognitive load. I find that anytime your eyes have to jump more than a few lines there's higher mental overhead

Definitely. But in that case, abstraction is my friend...

Re: Avoid Else, Return Early (2013)

#139

Post by Turing_Machine »

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

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..."

It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

Post reply on HN