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

501–510 of 601 posts

Re: Avoid Else, Return Early (2013)

#501

Post by ralusek »

Error handling early on with a throw or return is so much better because it just allows you to stop thinking the very moment you need to stop caring about the remainder of the function.

It's very much like any logic or debate, where you simply want to prevent getting into any of the details that occur further down the logical chain if you can already dismiss what is to come by detecting the exit condition early. There have been countless occasions where I've heard people having conversations for hours that should failed and exited early due to an exit condition at the very beginning of the conversation.

Re: Avoid Else, Return Early (2013)

#502

Post by Wildgoose »

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?

I sold my first program aged 15 and I'm 53 now. My experience is that the benefit of early return is to keep indentation to a minimum. To me, every time code indents it is a "context switch".

Having said that, early return should be for error/ignore situations - there should only be one return for a result and that should be at the very end of the function.

Re: Avoid Else, Return Early (2013)

#503

Post by RussianCow »

vanderZwan wrote: post #134
fouc wrote: post #119

Earlier quoted context omitted.

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 conte…

> There is a ton of code that only exists because of issues elsewhere in the code.

Or sometimes, not even that: issues elsewhere in the system, possibly completely outside of your control (e.g. the language/framework/library you're using, the OS, business requirements, etc).

Re: Avoid Else, Return Early (2013)

#504

Post by mr_toad »

z3t4 wrote: post #485
Bombthecat wrote: post #445

Earlier quoted context omitted.

I remember in my programming classes at school my teacher was always like: guys!there is space on the right! Use it! PS: he coded at Hercules the graphic cards back in the day before he got into teaching.

What is "Hercules the graphic cards" (I only found GPU's when trying Google)

The Graphics Card (HGC) was essentially an MDA-compatible monochrome card with an added all-points-addressable graphics mode.

https://en.wikipedia.org/wiki/Hercules_Graphics_Card

Re: Avoid Else, Return Early (2013)

#505

Post by efsavage »

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.

For glue/app/ux code that's mostly autocompleted, sure. But for domain-specific, algorithmic, magic-formula type stuff, comments are sanity made manifest.

Re: Avoid Else, Return Early (2013)

#506

Post by [deleted] »

z3t4 wrote: post #485
Bombthecat wrote: post #445

Earlier quoted context omitted.

I remember in my programming classes at school my teacher was always like: guys!there is space on the right! Use it! PS: he coded at Hercules the graphic cards back in the day before he got into teaching.

What is "Hercules the graphic cards" (I only found GPU's when trying Google)

[deleted]

Re: Avoid Else, Return Early (2013)

#507

Post by e12e »

sireat wrote: post #426
tom_mellior wrote: post #216

Earlier quoted context omitted.

Do they? All the Python folks I've ever seen express an opinion on style have said "follow PEP 8". Unsurprisingly, PEP 8 does have a rule for tabs vs. spaces: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces (spaces, of course)

I love Python but as a long time C programmer I can't understand the preference for spaces in PEP 8. Tabs are semantic and only take one key press for movement back and forth and to delete. If you see 1 tab you know it meant one indentation level. With spaces you have to think. Plus with spaces you are stuck with 2/4/8 spacing(unless you reformat), with tabs you can configure your editor to your preferences.

Tabs are semantic. But, when you start down that route, why not dictate record-separotor as replacement for closing brace/block etc?

Re: Avoid Else, Return Early (2013)

#508

Post by loup-vaillant »

macspoofing wrote: post #362
loup-vaillant wrote: post #214

Earlier quoted context omitted.

Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * Get the foo * * @return the foo */ int getFoo(); /** * Get the bar * * @return the bar */ float getBar(); /** * Set the foo * * @param foo the foo */ void setFoo(int foo); /** * Set the bar * * @param bar the bar */ void setBar(float bar); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int…

Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.

> It was generated by an IDE

Not all of it, actually.

> nobody had to physically type that

We totally had to read that.

> And usually no developer will be dwelling on this object or this area of the object.

Well… yes, usually. Sometimes however we did want to pay more attention than usual. At that point the original dev would have made a real comment. And that comment was lost in the noise, so you couldn't even distinguish between real comments and useless boilerplate.

Re: Avoid Else, Return Early (2013)

#509

Post by seanwilson »

optimuspaul wrote: post #108
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. 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.

> Unless you are writing completely brilliant code your future self will hate you if you skimp on comments.

The vast majority of comments I usually see can be rolled into variable names or function names. If you're writing lots of comments, that's a good indication your code is hard to understand, your variables are badly named and your functions are too long in my opinion. I think people that say "your code is bad if you don't have any comments" have things backwards personally.

Pretty much the only time I use comments is when I'm forced to write weird code to workaround an API bug, to explain an unintuitive optimisation or to give high-level architecture documentation.

I've honestly returned to code I've written myself maybe 5 years later and rarely had an issue that would have been helped with more comments.

Re: Avoid Else, Return Early (2013)

#510

Post by Xyik »

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…

this is so true, and my experience exactly.

one thing i do disagree with is commenting, there is a time in a place and its hard to derive on a rule on exactly where, when and how, but well placed comments are VERY important and can save developers a ton of time.

Post reply on HN