Hacker News Reader

Comment by tombert | Hacker News Reader

One opinion that seems to have completely changed since I first learned is about having a single `return` in my function. It was hammered into my when I first learned that you should only ever have one exit in your code, anything else is bad practice.

Fast forward about 11 years, and people realize that having a million nested if statements and matching else blocks is actually absurdly unreadable; much better to just return early, avoid nesting, and break the "only one exit" pattern.

View on HN

I'm big fan of separating functions into validation and logic using early returns:

  function doSomeStuff(input) {
      if(someInvariantIsUnsatisfied(input)) {
          return Error;
      }
      if(someOtherInvariantIsUnsatisfied(input)) {
          return Error;
      }

      //do stuff

      return result;
   }

The term for that is a "guard". Swift took it literally and introduced guard statements which force you to terminate the containing scope (return, throw, continue, break) or call a function that is marked as never returning. If control flow can ~~enter~~ exit the body of the guard statement without hitting one of those, it's a compiler error.

EDIT: Exit the body of the guard statement, not enter.

> ~~enter~~

I get you’re going for the non-standard markdown strike through, but that looks confusing and calls attention to something you meant to remove. You can (well, could) remove the word when editing.

It is possibly the one Markdown feature I'd like HN to have. I use it all the time on Reddit to correct my comments without making replies look like nonsense.

You can use unicode, l̶i̶k̶e̶ ̶t̶h̶i̶s̶

I find this the absolute most readable way to write defensive code. Huge fan.

I think that dates back to assembly where you have to clear up a stack frame before returning.

Especially when the code to do that depends on the amount of locals, having only a single place where you assign space for locals and a single one where you revert that helps a lot.

It also can help in languages that don’t help you run cleanup code (closing files, freeing memory) at function exit. Change the code and forget to update one of your early exits, and you have a bug. If that exit is rare, that may ship and may become a vulnerability.

Additionally, something that is forgotten now that structured programming won so hard, and so little assembly is hand-written, is that it's possible to return to different places. As in, in case A return to address F, but in case B return to address G.

The Linux kernel still uses centralized exits in places, with goto to do cleanup.

https://github.com/torvalds/linux/blob/master/Documentation/...

At my first programming job they were religious about the single `return' and followed a pattern that was bizarre and luckily I've not seen since--using a `retVal' variable declared at the top.

  int foo(int bar) {
    int retVal = -1;
    if (bar == 1) {
      retVal = 1;
    }
    if ((retVal % 2) == 0) {
      retVal = 2; 
    }
    return retVal;
   }

Yes, I've seen this a lot over the years.

Also, putting code inside a do ... while( false ) loop purely so you can use break as a sneaky goto to avoid deeply nested conditionals while technically adhering to the single return rule.

I think when you're starting to use control statements in bizarre ways like that, it's a good indication that maybe that's a case where breaking the "rules" is the best thing.

It might have improved in the last few years, but as of 2018, MSVC would not do named value return optimization for the case where all branches returned the same local variable, in my experience. There had to be just the one penultimate return statement, in order for NRVO to kick in.

Most of my teammates are in Serbia and I see naming the return object "toReturn" a lot... so yes, the code reads "return toReturn;"

My biggest pet peeves in the code I'm currently working. It leads to multiple multi-line ternary to keep a single return.

Single Return made sense when we had to de-allocate resources, but there are few years already that most languages have memory safe resource-counted allocations (C++11 for i.e) that will free resources correctly independent of your single/multiple returns.

I don't believe that keeping those inherited "best practices" from the past will help us developing modern code.

Long life to Clean Coding!

> It was hammered into my when I first learned that you should only ever have one exit in your code, anything else is bad practice.

Yes. This rule was an overreaction to a pervasive problem back in the day.

But, much like the use of "goto"s, there are times where your code is more readable, maintainable, and efficient if you ignore the prohibition. The trick is to know when that's the case.

Reply on news.ycombinator.com