6 ms·

I agree. Also if people really believe goto is bad, lets not forget the 'hidden gotos' like early return oder state machines.

dls2016 4y ago
I’ve worked with people who stick to “only one return statement per function”. Super annoying.
- cebert 4y ago
  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.
  - Tyr42 4y ago
    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
  - HWR_14 4y ago
    At the top of the function, "if [special input] return [special output]" is a great way of handling edge cases
- dhzhzjsbevs 4y ago
  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.
- StellarScience 4y ago
  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.
- zasdffaa 4y ago
  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?
ketzu 4y ago
The 'hidden gotos', especially like an early return, for me have stricter guarantees and limitations than a goto used in the same way. Goto and labels can do too much for me to like them, i prefer more specific things with clearer boundaries and intent.
- andi999 4y ago
  What are these guarantees? One is that they are easier to miss when reading the code.
  - ketzu 4y ago
    Sorry, I don't fully understand what you mean by that. Are "early returns" easier to miss when reading code (easier to miss than goto statements achieving the same effect)? If that was your intended meaning (sorry I am missing some sleep today) I don't share that view, I think both statements are equally obvious in that regard. Examples I was thinking about: * an early return can only go back to the call-site * all returns in a function or method return to the same place * an early return terminates the context it is in * an early return does not create an entry point for nearly arbitrary other code points as labels for gotos do

dls2016 4y ago

I’ve worked with people who stick to “only one return statement per function”. Super annoying.

cebert 4y ago
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.
- Tyr42 4y ago
  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
- HWR_14 4y ago
  At the top of the function, "if [special input] return [special output]" is a great way of handling edge cases
dhzhzjsbevs 4y ago
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.
StellarScience 4y ago
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.
zasdffaa 4y ago
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?

ketzu 4y ago

The 'hidden gotos', especially like an early return, for me have stricter guarantees and limitations than a goto used in the same way. Goto and labels can do too much for me to like them, i prefer more specific things with clearer boundaries and intent.

andi999 4y ago
What are these guarantees? One is that they are easier to miss when reading the code.
- ketzu 4y ago
  Sorry, I don't fully understand what you mean by that. Are "early returns" easier to miss when reading code (easier to miss than goto statements achieving the same effect)? If that was your intended meaning (sorry I am missing some sleep today) I don't share that view, I think both statements are equally obvious in that regard. Examples I was thinking about: * an early return can only go back to the call-site * all returns in a function or method return to the same place * an early return terminates the context it is in * an early return does not create an entry point for nearly arbitrary other code points as labels for gotos do