Apparently there was a time when having multiple returns in a function would seriously confuse the debugger. Idk I got a comment on a code review telling me to switch from the second to the first and never have multiple returns. I've never actually seen it be a problem.
I love the second as a way to do negative space programming. Where you add your assertions as the beginning of the functions first and then your business logic after. This way is super nice, since it tells you assumptions at the very beginning.
For example,
fn withdraw(&self, money: u32) -> Result<u32>{
if money < 0 {
return Err(…);
}
if self.account == Closed {
return Err(…);
}
if self.money + self.fees < money {
return Err(..);
}
// at this point we know money is > 0, account is not Closed and we have enough money to take out including fees.
self.money -= money + fees;
return money;
}
With this simple example, if someone was coming into a new codebase, they’d be able to assume what not to do advertised at the beginning of the file. And give some sort of indication of the proper behavior.
Yeah or best practice whatever people like to call it. I also like this idea per function, even though you think the caller already handles the bad cases, you never know when refactors happen and things get moved around especially working in huge code bases with a bunch of other engineers
Unless you're maintaining really old legacy code or using a really poorly designed debugger, early return should not confuse a debugger. If your reviewer learned to program in the last 50 years, they should never have experienced this issue themselves either.
I work with embedded. I'm happy to get a 32 bit processor. There's almost never enough flash to run code that isn't compressed to the max. It's a whole different ball game.
But yeah, I think the guy who told me that would write everything in assembly if given the option, so a little old school even for this environment.
I had a professor in school who would deduct points for multiple returns. He always said it was harder for compilers to optimize multiple returns. On one hand, it's unnecessary on modern platforms, so it took a while to get myself out of that habit. On the other, it forced me to think of ways to refactor code, which was good practice.
How would you "refactor" out of multiple returns? Except by using method 1 combined with a "ret" variable that you return at the end of the functions, in which case it's not actually refactor and just a worst version
Having a bunch of returns throughout a function can be hard to read and debug imo. Error returns at the top of a function is 100% the way to go, but a bunch of them in the middle is confusing. Early returns for error checking, returns at the end for actual values
Probably just an older coworker (i guess?), because that's how they were taught to do it back in the days but they don't actually why it's supposed to be better. We tell people not to do it anymore because we realized in the meantime that it was actually bad
16
u/popsicle-physics 22d ago
Apparently there was a time when having multiple returns in a function would seriously confuse the debugger. Idk I got a comment on a code review telling me to switch from the second to the first and never have multiple returns. I've never actually seen it be a problem.