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

271–280 of 601 posts

Re: Avoid Else, Return Early (2013)

#271

Post by lisper »

hailk wrote: post #257
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.

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

Re: Avoid Else, Return Early (2013)

#272

Post by ainiriand »

kstenerud wrote: post #167
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.

I've done a number of informal tests on friends and family over the years regarding brace placement, and it's always been the same: For someone with NO experience programming (i.e. looking at what to them seems like a bunch of gobbletygoop - and what's a "text editor"?), adjacent braces make it appear more readable than same-line braces. It's only people who cut their teeth on adjacent bracing that find it more reada…

'I've done a number of informal tests on friends and family'

You should have a pretty cool family!

Re: Avoid Else, Return Early (2013)

#273

Post by shadowfiend »

This makes sense only when you have to have an explicit return point. In languages that return the last expression, I find it much more palatable to represent your conditions as top-level if expression.

A conversion of the base example would be:

    function () {
      if () {
        x
      } else {
        if () {
          y
        } else {
          z
        }
      }
    }
Granted it's also worth noting in such a language I rarely find myself using `if` and `else`. More likely I'm doing flow control based on `map` and some version of `getOrElse` (Scala's term for Option that allows you to return an existing value or alternate to a nonexistent value). These abstractions tend to compose better, and lead to more clarity as to what particular data item is leading to the value being one thing or another; e.g.:

    function() {
      requestValue orElse sessionValue getOrElse defaultValue
    }
If requestValue is defined, return it; otherwise, if sessionValue is defined, return it; otherwise, return defaultValue. While not all conditions are immediately expressed this way, many of them can be simplified to data flow decisions that can be expressed this way, and the exercise of reworking the solution to use this strategy clarifies the surrounding program as well.

Re: Avoid Else, Return Early (2013)

#274

Post by [deleted] »

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

[deleted]

Re: Avoid Else, Return Early (2013)

#275

Post by dep_b »

wildmusings wrote: post #35
dep_b wrote: post #20

Earlier quoted context omitted.

`goto` wouldn't be used in a return early philosophy.

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.

Not a C-programmer at all but I would separate out the resource creation/access from acting on the resource. So Open X, Do Y on X, Close X would have do Y on X in a separate function and possibly Open X and Close X as well. This way Close X would be executed regardless of the result of Do Y on X.

Only by doing multiple things in one function you really need to use goto's in C. (again, as far I can judge coding in C, not an expert!)

Re: Avoid Else, Return Early (2013)

#276

Post by RobertRoberts »

JoeAltmaier wrote: post #228
melling wrote: post #225

Earlier quoted context omitted.

The One True Brace Style: https://softwareengineering.stackexchange.com/questions/9954... The name tells you that it won.

That link's favorite response actually refutes that brace style matters at all. No correlation with bug frequency detectable. So its all religion.

It's not "religion" if there's a technical reason to choose one method over another.

A later comment on the SO post described how K&R can have maintenance costs because when moving things around it's more difficult to tell where a statement ends, and can accidentally cause side effects.

Re: Avoid Else, Return Early (2013)

#277

Post by SideburnsOfDoom »

z3t4 wrote: post #244
SideburnsOfDoom wrote: post #38

Earlier quoted context omitted.

> single exit point rule, What makes it a "rule" or as sometimes said, a "law"? It's just a style, and it has pros and cons, cases where it helps, and cases where it hinders.

It's interesting when style becomes rules, the years goes by and no one challenge the "best practice", languages and frameworks might change, but the rules stay, for no good reason. So yeh, why only one return !?

> So yeh, why only one return !?

Because it was a good idea in C.

it's pretty much irrelevant to Java, JavaScript, C#, Ruby, Python, Rust etc.

But the rules stay, for no good reason.

Re: Avoid Else, Return Early (2013)

#278

Post by ajuc »

drawkbox wrote: post #220
ajuc wrote: post #181

Earlier quoted context omitted.

Did you mean to use for with no counter instead? If so - I strongly disagree. I much prefer while(condition) {} to for (;condition;) {} For one thing you can't misplace ";" in a while loop. I agree that "do while" loops are unintuitive and rarely used, and thus the place to first check for bugs. Also they save very little so I just implement them as do(); while usually. But I know people who disagree about that, too,…

Basically what I am saying is while should be mostly off limits. But yes if you end up in a loop you have some sort of counter/null checks or way out if you end up in a constant/recursive loop. Never leave open the possibility of a lock due to being stuck in a loop.

You want to write "cat" equivalent. How do you do the loop?

I think for loops should be limited to iteration over collections, or repeating sth known number of times.

There are cases when you need to decide if you want to continue iteration on the fly, and while loop is the perfect tool for that. Also while loop is arguably less error-prone than for loop: can't swap clauses because there's just one, can't write "," instead of ";" by mistake.

Re: Avoid Else, Return Early (2013)

#279

Post by lisper »

alunchbox wrote: post #157
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.

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 figure out how to restore the proper block boundaries after a cut-and-paste has screwed up the indentation.

Re: Avoid Else, Return Early (2013)

#280

Post by JackFr »

psyc wrote: post #183
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.

I've also been coding 30 years. I have to use same line at work, and I use next line in my (very large) side projects. Honestly, I don't know what the difference is.

> (very large) side projects

How big once you remove all the extra newlines?

Post reply on HN