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

291–300 of 601 posts

Re: Avoid Else, Return Early (2013)

#291

Post by RobertRoberts »

psyc wrote: post #197
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…

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?

Re: Avoid Else, Return Early (2013)

#292

Post by RobertRoberts »

drawkbox wrote: post #75
tzahola wrote: post #72

Earlier quoted context omitted.

>Same way while/do/while is usually fades away, and if needed exit conditions. I couldn't interpret this sentence.

Edited, basically do not use while loops, if you do tread carefully and provide yourself an exit. You don't want to be the one that nukes the server.

I learned about while loops at the beginning of my career, and after a few scary errors, I never used them again. 20 years of no while loops anywhere... never going back.

Re: Avoid Else, Return Early (2013)

#293

Post by hailk »

lisper wrote: post #271
hailk wrote: post #257

Earlier quoted context omitted.

I see it the same way. It offers symmetry. The method name can be as long or short. At least the start of the code block and the end is easily visible since the indentation level remains same. Gives a sense of Python readability.

Huh? My emacs auto-indents both styles in exactly the same way: void foo() { code...; } void foo() { code...; }

The start of the code block is signified by the opening brace, which starts at the end of the method name in the first case, hence breaking symmetry.

Re: Avoid Else, Return Early (2013)

#294

Post by sgustard »

timoxley wrote: post #78
Waterluvian wrote: post #51

Earlier quoted context omitted.

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.

A big gotcha with `&&` as a guard in JS is that it can return any falsey typed value if you don't coerce the guard to a boolean. e.g. const check(cond) => cond && otherValue If `cond` is falsey, it returns `cond`. This means the function could return any of: `false`, `undefined`, `null`, '', `0` or `NaN`. This is a fairly common issue I see with React + JSX: {cond && } If `cond` is `false`, `null`, `undefined` or '',…

Yes, back when CoffeeScript was in vogue the ? operator handled this case nicely:

  cond? && otherValue

Re: Avoid Else, Return Early (2013)

#295

Post by timoxley »

simias wrote: post #107

I always found this type of "general purpose" coding rules rather useless and often counter-productive because some coders (especially beginners) will often cargo-cult and apply them without rhyme or reason. I've known coders who had the opposite rule: never have more than one return per function, use if/elses for the control flow (TFA mentions that). I don't know where this rule came from and neither did they, it's…

I'm trying to imagine worst case scenarios here, and at least in an environment like JavaScript, I'm struggling to see how a beginner being overeager with early returns can possibly create anywhere near the same degree of mess as a someone overusing nested if/else statements.

Agreed on early returns being questionable for "two variations of the same concept" though, these days I generally use if/else for situations like that.

Re: Avoid Else, Return Early (2013)

#296

Post by [deleted] »

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…

[deleted]

Re: Avoid Else, Return Early (2013)

#297

Post by gruez »

ajuc wrote: post #186
scott_s wrote: post #173

Earlier quoted context omitted.

When you read through a part of your system that you've either never seen before or have forgotten how it works, do you also read all commit messages for all of that code? I'm asking because that's the only way I can imagine one can learn about the edge cases and surprising consequences in non-trivial systems if you have a rule about not using comments to explain them.

No, I do a git blame, and see all the relevant commit messages. If there's not 1 line of code from that commit remaining why is it relevant? If something looks weird still - I go back to the commit that created this part of code and git blame that. I don't remember a case where I had to do 2 steps like that. BTW we have a rule of putting JIRA ticket numbers in commits, that makes it even easier to find out. You can s…

>No, I do a git blame, and see all the relevant commit messages.

sounds great until there's a refactor (including moving code around), then all the "comments" get buried.

Re: Avoid Else, Return Early (2013)

#298

Post by phamilton »

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.

I find the better my types are, the less I need to explain. Canonical morphisms generally don't need comments.

Re: Avoid Else, Return Early (2013)

#299

Post by RobertRoberts »

feedmeseymour wrote: post #88
franciscop wrote: post #81

Earlier quoted context omitted.

Exactly, I did all of the above. Spent too many hours fixing broken code (of my own) and finally I started to learn. What about error handling? No mention here. What I do not is let the library/framework to handle most of it. With a recent server library I wrote, I can throw anywhere and it will be caught and displayed as expected without extra try/catch.

Errors are the exception, not the rule :)

Can't tell if a logical point or a pun...

Re: Avoid Else, Return Early (2013)

#300

Post by bjourne »

viach wrote: post #3

"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.

Ceteris paribus, shorter code always is more readable. It's the only guideline I've found true regardless of programming language or environment. Shorter is better.
Post reply on HN