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

311–320 of 601 posts

Re: Avoid Else, Return Early (2013)

#311

Post by pdonis »

jorams wrote: post #266
bipson wrote: post #127

Earlier quoted context omitted.

I disagree. Consider the absurd example where every single statement is crammed into a single line. Not exactly readable to me? Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.

That's covered by "all things equal". The argument against placing braces on their own line is that this: if (a) { print(a) } conveys exactly as much information as this: if (a) { print(a) } while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.

> The thing the brace tells you is already told by the indentation

Which is true, and of course begs the question: why do you even need the braces?

Re: Avoid Else, Return Early (2013)

#313

Post by cesarb »

Grue3 wrote: post #238

In Common Lisp the syntax for early return is so ugly (```(return-from function-name result)```) that I use it very rarely. In general, it seems that in the languages that use implicit return (Lisps, Haskell, Rust?) having an early return is discouraged by design.

Early return is very common in Rust, either explicit or hidden within the try! macro (which recently became the ? operator, since it was used so often).

Re: Avoid Else, Return Early (2013)

#314

Post by mstade »

maxxxxx wrote: post #203
koolba wrote: post #95

Earlier quoted context omitted.

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

I always tell my team that deleted code is the best code. Obviously less code is often more maintainable but there is also the element of being willing to throw away stuff you did earlier and not being attached to it.

I have a similar take on this, but expand it a bit by arguing that any line of code added – no matter how innocuous – is a liability. It's a line of code that has to be maintained, with all of the responsibilities that come with that. It may be a line that's responsible for adding more value than it costs, but it's still a liability. It won't add value forever, most likely, and when it stops it'll just be debt. It may be cheap debt, but debt nonetheless.

Deleted code on the other hand, is never a liability. The act of deleting it may be, but due diligence should ensure it is not.

Re: Avoid Else, Return Early (2013)

#315

Post by jwilk »

citation_please wrote: post #4

Seems to me that there is quite a bit of commentary on this subject, and you can find it by searching for its typical solution: guard clauses[1]. [1] http://wiki.c2.com/?GuardClause

Copy of the article, which doesn't require JS:

https://gist.github.com/jwilk/6e7ecb94b623a82d01cdcd9765f05b...

Re: Avoid Else, Return Early (2013)

#316

Post by vpribish »

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…

Wow, you captured so many things I saw in my own education. let me add one:

Same way you learn to let some code fail instead of handling every exception.

Re: Avoid Else, Return Early (2013)

#317

Post by nippur72 »

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…

> Programmers with lots of hours of maintaining code eventually evolve to return early

indeed I've evolved it myself but always wondering if it was the right thing to do. Now I even have a name for it.

Re: Avoid Else, Return Early (2013)

#318

Post by kbenson »

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 move on from single condition bracket-less ifs.

This is one of those things that whether you drop it or not, you recognize the times it's caused you severe pain because you didn't notice it was single line when adding a statement, such as a debugging one, and all of a sudden the conditional part isn't what you were expecting.

This is actually one of the things I love about Perl. Single line conditionals were changed so they both looked different, and they only allow a single statement. e.g.

    if ( condition ) statement;
becomes

    statement if condition;
Regular if blocks still work as expected, but there is no braceless version of regular if conditions. I understand many people find it jarring at first, but it does allow for clear and concise precondition and return early statements, especially when grouped together. e.g.

    return undef if $param1  100;
    die "Not a number" if not looks_like_number($param1);

Re: Avoid Else, Return Early (2013)

#319

Post by DanHulton »

optimuspaul wrote: post #111
Merad wrote: post #106

Earlier quoted context omitted.

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.

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.

I've actually evolved a hybrid style in my personal projects - next line for functions/classes, same line for blocks.

To me, it looks weird when functions don't have that extra line of space to set off their definition, but if/while/whatever aren't special enough to need that call out.

That said, the most important factor is simple consistency. In my person projects, I have the hybrid style. At work, I use same-line-only. If I'm on a project that has next-line, we all use next-line.

Re: Avoid Else, Return Early (2013)

#320

Post by jstimpfle »

monocasa wrote: post #211
weinzierl wrote: post #200

Earlier quoted context omitted.

> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…

That's one of the reasons I love RAII; all resources, memory and otherwise, are treated the same.

Downside is, now your cleanup code is spilled all over the codebase. And where it's implemented it lacks often the necessary context (from the location of use). So, it's often wrong or incomplete, or suffers from the type-for-single-usage syndrome.

Yes, RAII works for the casual std::vector, but it's not a maintainable solution for general resources.

Post reply on HN