Re:We Are Sorry to Inform You (2005)
by dls2016 on Saturday June 18, 2022 @08:33AM
(#31789264)
I’ve worked with people who stick to “only one return statement per function”. Super annoying.
[ Parent
| on HN ]
Re:We Are Sorry to Inform You (2005)
by dhzhzjsbevs on Saturday June 18, 2022 @11:39AM
(#31790835)
The no else statement shit drives me up the wall. Sometimes code is more readable when it says what you mean. Sometimes I want to branch, other times I want to return early. There is a difference in what I mean and code should reflect that even if the opcode is the same.
I'm one of those and rather unsure of its value. The original reason is the modelling of the program as a reducible graph (if I'm not getting confused with other stuff).
I occasionally have a couple of returns in one func but only for very, very simple and short funcs where it's clearer.
I dunno. Perhaps the problem is we're missing some higher level procedural construct - any ideas?
I think it depends on the situation, but a single return statement per method does make it a bit easier to read a method and understand flow control.
At the top of the function, "if [special input] return [special output]" is a great way of handling edge cases
Really exit can be pretty useful though.
Doing if(condition) return at the start, before it gets going often reduces indentation and how many branches you need to see at once.
But I can agree sneaky returns can bite you sometimes
Re:We Are Sorry to Inform You (2005)
by StellarScience on Saturday June 18, 2022 @12:33PM
(#31791390)
We've adopted single entry / single exit except for short functions (< 10-15 lines), where all the returns are clearly visible at once. It seemed to placate both sides, and it allows you to write that simple 'findFoo' function that returns 'foo' as soon as it finds it.