Hacker News Reader

Comment by Timothycquinn | Hacker News Reader

I had a teammate state that Gates at the beginning of functions were also spaghetti code. E.g: If <condition>: return.

My teammate had learned that rule. from his CS teacher.

I use Gates regularly as they reduce the need for indentation which I believe is a much bigger spaghetti problem. Nothing worse than debugging 7 levels deep of indentation on a function with many pages of code. I also use Goto if the language supports them and it makes the code easier to grok.

But hey, I'm self taught with no College CS degree so what do I know ;)

View on HN

ReSharper for C# discourages nesting and favours early returns instead. Having personally had the displeasure of working with code that does the opposite, I have to agree that it's the better option.

That's the "single entry, single exit" guideline. See https://softwareengineering.stackexchange.com/questions/1187... and places it links to (like https://stackoverflow.com/questions/36707/should-a-function-... ).

I've heard second-hand about places which follow that guideline. I'm against it, for reasons you and others say.

BTW, those are usually called "guards", not "Gates". https://en.wikipedia.org/wiki/Guard_(computer_science) .

I actually agree with your teammate (moreso than you, anyway). You now have a single entry point with multiple exit points in your code, which is clearly halfway to spaghetti (even if you think it's warranted).

Your gripe is about indentation being too much to bear, which is a pretty superficial thing to complain about, and it's not even clear what your complaint about it is/why it's actually bad. It's just indentation... you can live with that imperfection on your code. It's not the end of the world. I know I'm a pretty happy developer whenever I can reduce other problems to mere indentation (which I can, explained below).

To me, every level of indentation actually conveys useful information: it tells me "hey, here's yet another precondition for this line of code", and crucially, it tells me that information at that line, without me having to keep scrolling up the function and then mentally negating the early-return condition to figure out what the precondition is. That's incredibly useful on its own. So many fixes & simplifications result from merely noticing "hey, this function has 3 preconditions, but I thought it should only have 2... what's going on?" And yet that's not all.

Beyond that: Not having early returns means there's a single entry and exit point for each procedure. That is also incredibly valuable in its own right. Try adding a simple print()/log() statement before the function returns when you have like 6 early returns in the function. At best, you remember to do it, but it's a ton of duplicated (and bloated) code, and your maintenance work just got 6x harder, and you have to keep them all in sync as the code grows (so it's greater than 6x harder). At worst you just miss half of them (or someone who adds another early return forgets to do any final steps beforehand) and now you introduce a bug. And on top of all that, it's so painful to leave a breakpoint and then realize a while later that it wasn't getting hit in every situation you expected, because there was an early return in the function that you didn't notice.

I could go on, but all this because there's "nothing worse" than some extra indentation?

Early return makes it easy to reason that the rest of the code in the function is unrelated to whatever you're checking for right now. Having multiple exit points in a function is not the end the world.

If you need to print()/log() before return, then just replace them with goto (if your language supports it). After debugging if you have no more use for print()/log() statements you can remove just those statements and keep goto as it is.

My heuristic is to prefer flatter code. Thus, I tend to use guards quite liberally, but I also tend NOT to use

  if (condition){
    expression; 
    break/return;
  }

Gates at the beginning of functions are the pre-conditions in design by contract, so it tells quite a bit about that CS professor, him calling them spaghetti code.

Maybe something you would like to dive into,

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

I think it's situation specific as the effect of adding another layer of indentation compounds.

That said, if either the indentation is too deep or there are more than one or two guards at the top it's probably a sign that the method should be broken out either way.

Maybe the exception to this is recursion? You must have early return statements for the base case

No, you could wrap the whole function body in an

    if (!base_case) { 
        // one more indentation level!
        ...
    }

if you adhered to the belief that early returns decrease readability.

I call this

'fail fast'

Reply on news.ycombinator.com