5 ms·

> My reasoning is that the reader should know at each line what conditions are assumed. I don’t get it. How do early returns not convey assumptions that can be

> My reasoning is that the reader should know at each line what conditions are assumed. I don’t get it. How do early returns not convey assumptions that can be made in the rest of the function? > Returning in the start is as anti-pattern for me as goto in the middle. both of them leave you with lines of code that only a debug session (in mind or in action) can tell you what lines will be called. This is really confusing to me. What do you mean by “in mind or in action”? In any case, if you have runtime conditions you can’t tell what code will be executed in general just by looking at the code regardless of whether you’re looking at nested code or code with early returns. > I will choose nested code any-day if that means i can simply follow what `if`s are relevant rather than guessing. Are the conditions for early returns not relevant or something? What about them leaves you guessing?

duncan-donuts 8y ago
In mind or in action means either your running the logic through your head to debug or you’ve set a break point and you’re actively debugging
yonixw 8y ago
they are all gathered at once.the following lines could assume any combinations of those conditions. in simple examples it is not an issue but as the function get more complex I found it excruciating.
- aw1621107 8y ago
  > the following lines could assume any combinations of those conditions. Do you mind expanding a bit more on this? From what I understand, if you have early returns the only way you can get into the rest of the function is if all of the conditions pass, not any arbitrary combination of them. Also, do you have an example of a more complex function with early functions that you find difficult to read?
- de_watcher 8y ago
  I just soak everything in asserts. That way there is no need to scroll up for preconditions, be it a nested tree or some returns at the start. And when you move a small piece of code, you're told exactly what you should be thinking about, you need to decide what to do with that assert that represents an assumption.
dsego 8y ago
I think he means that when you see a block of straight non nested code, you assume it can be yanked out or moved around without penalty. That is, the conditions and the actual code are not visibly connected and you have to trace the dots. But when it's nested it's immediately more clear that the nested code depends upon some conditions.
- aw1621107 8y ago
  That's an interesting point. I'm not entirely sure I agree with that reasoning for early returns, though. If I'm extracting code to be available for more general use, I usually prefer to try to forget the preconditions of the source function and apply just the preconditions that are applicable for the now-standalone code. In that case, once I'm done with the extraction I'd need to ensure that the preconditions of the source function match the preconditions of the extracted code, and nesting doesn't really affect that; if anything, having the preconditions all up front would make things a bit easier by having everything in one place. As for moving blocks of code around, I can't say I've had much need to move code across "precondition domains", for lack of a better term. Perhaps I just haven't run across the right situation yet.

duncan-donuts 8y ago

In mind or in action means either your running the logic through your head to debug or you’ve set a break point and you’re actively debugging

yonixw 8y ago

they are all gathered at once.the following lines could assume any combinations of those conditions. in simple examples it is not an issue but as the function get more complex I found it excruciating.

aw1621107 8y ago
> the following lines could assume any combinations of those conditions. Do you mind expanding a bit more on this? From what I understand, if you have early returns the only way you can get into the rest of the function is if all of the conditions pass, not any arbitrary combination of them. Also, do you have an example of a more complex function with early functions that you find difficult to read?
de_watcher 8y ago
I just soak everything in asserts. That way there is no need to scroll up for preconditions, be it a nested tree or some returns at the start. And when you move a small piece of code, you're told exactly what you should be thinking about, you need to decide what to do with that assert that represents an assumption.

dsego 8y ago

I think he means that when you see a block of straight non nested code, you assume it can be yanked out or moved around without penalty. That is, the conditions and the actual code are not visibly connected and you have to trace the dots. But when it's nested it's immediately more clear that the nested code depends upon some conditions.

aw1621107 8y ago
That's an interesting point. I'm not entirely sure I agree with that reasoning for early returns, though. If I'm extracting code to be available for more general use, I usually prefer to try to forget the preconditions of the source function and apply just the preconditions that are applicable for the now-standalone code. In that case, once I'm done with the extraction I'd need to ensure that the preconditions of the source function match the preconditions of the extracted code, and nesting doesn't really affect that; if anything, having the preconditions all up front would make things a bit easier by having everything in one place. As for moving blocks of code around, I can't say I've had much need to move code across "precondition domains", for lack of a better term. Perhaps I just haven't run across the right situation yet.