Hacker News Reader

Comment by needle0 | Hacker News Reader

When I found out about the 1st pattern I liked it, but at another workplace I was advised to avoid it since it creates multiple exit points for the function, leading to confusion. I'm not quite convinced of that and tend to agree with the author of this article, but are there any other arguments against it?

View on HN

There's a very old programming style rule about only ever having one entry and one exit to a function. This rule dates back to the days of assembly programming, where any 'function' could just jump directly into the middle of some other function, or jump out before the end. This made understanding and maintaining code super-difficult, and this rule made a lot of sense.

Eventually, "structured programming" languages like C and Pascal were invented, where you couldn't just leap from one arbitrary part of the program to another. In these languages, the compiler enforced that each function had a single entry point, solving part of the problem. However, for C in particular the rule was still kind of useful - all the resources allocated during the function needed to be cleaned up by the end, so it was still good practice to have a single exit point that always did whatever cleanup was required.

These days, most languages have a garbage collector that will automatically clean up for you. Languages that don't have a garbage collector, like C++ and Rust, generate all the deallocation logic at compile time (the RAII idiom).

If you're using a language designed after the early 1980s, the "single entry and single exit point" rule is either wholly irrelevant, or does more harm than good.

To me,that depends on the language. If you are using C, it's probably best to have one exit point where everything that needs to be cleaned up is taken care of. If it's C++ (RAII/scoped lifetimes) or another language that does not require manual cleanup, maybe it's fine to return early.

I personally never use this pattern because I like having a central place to cleanup/set status/return values etc. I also find it easier to add/remove more functionality that way.

The code that I have most often seen using early returns is in large functions that do several things, so they're exacerbating poor design with confusing flow of control.

I feel that if you keep your functions small enough, you can keep them readable either way. So I'm back to mostly worrying about cleaning up resources in a consistent way.

I think having multiple exit points is good when the early exits are all at the beginning for trivial parameter validation, but likely to be bad if they're buried in the middle of the function.

In either case, there's the disadvantage that if you want to do printf debugging and make the function print "function foo returned 'false'" when it returns, early return makes it a pain. (Generally not so much a problem for real cleanup work, since your early returns are likely before the function's actually done any work that needs cleanup)

It's hard to argue against one-liner early exits at the very beginning of the function.

Although I've been avoiding multiple exists, I don't think the the patten is that bad, just more of personal taste. However, I think it's import to let the readers of the function know what the function mainly do first, insead of the edge cases.

In functional thinking, it's actually very helpful to think of the edge cases and get them out of the way first. When put in coding, I like to think it's more helpful to let the readers know the purpose of the function first, they could dig deeper later if they choose to.

Back in the mid 80's my more computer sciency coworkers gravely warned about 'bad things' that would happen if you had multiple returns.

I found multiple returns were useful places to stick break points[1]. Like when you're trying to track down a rare error condition that happens every so often. Like once a week.

[1] I use a debugger cause I'm a small brained primate.

Reply on news.ycombinator.com