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

381–390 of 601 posts

Re: Avoid Else, Return Early (2013)

#381

Post by ravitation »

josephv wrote: post #270
ivanhoe wrote: post #218

Earlier quoted context omitted.

In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...

Pragmatic programming has lost. If you aren't a zealot about being pedantic, just move into the old-folks home.

I enjoy zealous pedantry. I have strong personal opinions about something that I do a lot (especially the pedantic parts), but most of it is relatively lighthearted.

Re: Avoid Else, Return Early (2013)

#382

Post by mark-r »

Small bit of trivia: the 8080/Z-80 microprocessors had conditional return instructions that were only a single byte long. I utilized these instructions heavily when trying to cram my code into a single EPROM, because the jump instructions were 2 or 3 bytes.

Re: Avoid Else, Return Early (2013)

#383

Post by timoxley »

ebbv wrote: post #148

Good advice except for the last example which is brittle and unnecessary. If handleError() is ever changed this method could start returning values unexpectedly. Totally unnecessary and not a worthwhile "optimization" to save lines of code.

The `err, results` params form the signature of a continuation-passing style "errback":

    function(err, results) {
      if (err) // …
    }
It is assumed that this function will be executed asynchronously, and thus it's not possible for anything to consume the return value anyway.

If you want to control the return value, simply return on a new line or use the void operator:

   return void handleError(err)

Re: Avoid Else, Return Early (2013)

#384

Post by timoxley »

hnaccy wrote: post #185

Removing the braces and returning the unneeded non-result of handleError to save a couple LOC is penny wise pound foolish. Is this a common JS idiom?

The `err, result` signature of the function indicates that it will be executed asynchronously, and thus the return value can't be captured by anything anyway.

Re: Avoid Else, Return Early (2013)

#385

Post by sorenjan »

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…

That's called a predicate and is used in Scheme as well.

Re: Avoid Else, Return Early (2013)

#386

Post by timoxley »

ams6110 wrote: post #160

> We also generally don’t care about return values in JS I don't find that to be the case, though JS isn't my main language.

Post is referring to async programming in node's callback style (non-promise-based functions executed asynchronously) where return values cannot be captured even if you want to.

Re: Avoid Else, Return Early (2013)

#387

Post by lisper »

true_religion wrote: post #373
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…

Python specific IDEs will smartly indent code upon copy and paste.

Sure, but if you somehow manage to screw up the indentation then no IDE can possibly restore it for you because the information needed to do it is lost. And there are a LOT of ways that indentation can get screwed up. If your code ever leaves the Python ecosystem (e.g. gets published on the web) then all bets are off because the entire digital world outside of the Python-sphere is built on the assumption that whitespace is fungible.

Re: Avoid Else, Return Early (2013)

#388

Post by Zyst »

josephv wrote: post #270
ivanhoe wrote: post #218

Earlier quoted context omitted.

In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...

Pragmatic programming has lost. If you aren't a zealot about being pedantic, just move into the old-folks home.

Not at all, I'd argue this whole Tabs/Spaces, bracket placement, single/double quote discussion should be getting killed by code formatters.

At the end of the day you can do whatever you want with the code you're writing, and some pre-commit hook can run go fmt/prettier/whatever and then it'll all get standardized.

I've become a very heavy proponent of code formatters (I added prettier to the entire team) and I truly believe that talk about code formatting will never really die off, but at the end of the day you can do whatever you want on your side but still have a standardized looking codebase, and that feels extremely liberating to me.

As a PS: If you are a diehard tab proponent/different bracket placement/whatever but your team formatter configuration uses spaces instead then you can also use code formatters to do spaces -> tabs locally, say, on file open. Once you commit your file your precommit falls back to the team configuration, which removes your tabs. Everyone is happy.

Re: Avoid Else, Return Early (2013)

#389

Post by ohazi »

ivanhoe wrote: post #218
optimuspaul wrote: post #111

Earlier quoted context omitted.

Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.

In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...

Just give me an opinionated ${LANG}fmt utility to do it for me so I don't have to care and don't have to waste time arguing with other zealots. Let the tool be the zealot.

Re: Avoid Else, Return Early (2013)

#390

Post by chaboud »

psyc wrote: post #205
chaboud wrote: post #22

I think there's a lot of value to returning early out of functions when you hit an error condition. There's not much reason to go further if you're just completely hosed. (e.g. malformed arguments). However, I don't think that coders should shy away from built-up result values for return. It makes the code more friendly to things like copying (I can feel the boos and hisses now), block restructuring, #ifdef'ing (or s…

Guard clauses aren't only for errors. They do however usually involve certain kinds of asymmetry. Typically: The early return case does fewer things (or nothing) than the major case. Or the early return case is normal, but has a 'negative' sense (which again does less work) like not finding a key in a dictionary.

I agree with you.

I think the statement (ish) “don’t use if/else, use return” deserves some qualification, and one natural place to use it is for errors.

When people start dropping returns all over massive multi-screen branching and looping structures, readability may suffer, and debugability quite often takes a big hit.

In general, I like to use guard clauses for any big at-entry branch asymmetries. If they’re farther down the logic tree and/or unwieldy, it may be time to call some more functions.

Post reply on HN