5 ms·

For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well

by psyc 9y ago

For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well as continue early in loops) and I cannot go back. The immensely reduced indentation is marvelous. Having that 'happy path' consolidated is more readable.

maxxxxx 9y ago
I am on board with returning at the beginning while checking arguments. But I hate it when code returns somewhere in the middle for some reason. I have spent countless hours debugging a problem with unexpected behavior only to find a return statement in the middle of a huge block to code.
- augustk 9y ago
  That's because the return statement is a kind of goto statement. Goto-like statements reduce the value of structured programming. In a pure structured program, each statement sequence is either completely executed or not executed. There are also pure structured languages, like Oberon, which doesn't allow impurely structured programs.
  - maxxxxx 9y ago
    When return is used in the middle of a complex code sequence I much prefer a goto so at least I know where all paths exit.
RobertRoberts 9y ago
I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?
- macspoofing 9y ago
  The problem is that for any rule you come up with there are cases where that rule is just too rigid and too inflexible. There are times where early return makes a ton of sense. Usually that's the case when you can derive the return value from a shallow interpretation of some input values (i.e. check preconditions) but still require more complex processing for other input values. In that case, return early, but constrain the rest of the method to one return point. On the flip-side, there are cases where an early return makes it incredibly hard to reason about the function. This usually occurs in dense, nested conditional logic. In those cases, I found sticking to rule that a return value should be initialized once and only once, and return from a single point, beneficial in even reasoning about the problem.
  - RobertRoberts 9y ago
    Can't that be taught as well? (both rules, and exceptions to rules?)
    - macspoofing 9y ago
      Sure. But as a novice youd should adhere to rules. As you gain experience you learn when to break them.
      - RobertRoberts 9y ago
        I think you read my comment backwards. I think the "rule" should be "exit early", and the exception "multi-indent exit later".
- Wildgoose 9y ago
  I sold my first program aged 15 and I'm 53 now. My experience is that the benefit of early return is to keep indentation to a minimum. To me, every time code indents it is a "context switch". Having said that, early return should be for error/ignore situations - there should only be one return for a result and that should be at the very end of the function.
- 9y ago

by psyc 9y ago

maxxxxx 9y ago

I am on board with returning at the beginning while checking arguments. But I hate it when code returns somewhere in the middle for some reason. I have spent countless hours debugging a problem with unexpected behavior only to find a return statement in the middle of a huge block to code.

augustk 9y ago
That's because the return statement is a kind of goto statement. Goto-like statements reduce the value of structured programming. In a pure structured program, each statement sequence is either completely executed or not executed. There are also pure structured languages, like Oberon, which doesn't allow impurely structured programs.
- maxxxxx 9y ago
  When return is used in the middle of a complex code sequence I much prefer a goto so at least I know where all paths exit.

RobertRoberts 9y ago

I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?

macspoofing 9y ago
The problem is that for any rule you come up with there are cases where that rule is just too rigid and too inflexible. There are times where early return makes a ton of sense. Usually that's the case when you can derive the return value from a shallow interpretation of some input values (i.e. check preconditions) but still require more complex processing for other input values. In that case, return early, but constrain the rest of the method to one return point. On the flip-side, there are cases where an early return makes it incredibly hard to reason about the function. This usually occurs in dense, nested conditional logic. In those cases, I found sticking to rule that a return value should be initialized once and only once, and return from a single point, beneficial in even reasoning about the problem.
- RobertRoberts 9y ago
  Can't that be taught as well? (both rules, and exceptions to rules?)
  - macspoofing 9y ago
    Sure. But as a novice youd should adhere to rules. As you gain experience you learn when to break them.
    - RobertRoberts 9y ago
      I think you read my comment backwards. I think the "rule" should be "exit early", and the exception "multi-indent exit later".
Wildgoose 9y ago
I sold my first program aged 15 and I'm 53 now. My experience is that the benefit of early return is to keep indentation to a minimum. To me, every time code indents it is a "context switch". Having said that, early return should be for error/ignore situations - there should only be one return for a result and that should be at the very end of the function.
9y ago