You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think you make a very solid point in that section when you say that:
I do think you should be careful about the flow control part of return creating more implicitness in your function definitions. Try to figure out the most explicit way to express the logic; that will often be the best way.
But in your example I feel you do just the opposite. You add an extra variable that I need to keep track just to know if I should still execute the code to come. You say that:
every branch where retValue can get set is guarded by the condition that checks if it's already been set.
But that was already the case with the returns, with the added bonus that once you hit a return you can forget the rest of the function.
I feel that if you execute both codes in your head, the former gives you some breathing space once you hit a return, whereas the latter forces you to go all the way through, just to realize at the end that you didn't.
I am not saying that you are wrong when you say that returning too often can make the function harder to read, but I would argue that in this example you actually do have all those points where you do need to return.
I think a nicer example to make your point would be edge cases, where dealing with the edge case before the main logic can make it harder to understand what it is you are trying to achieve with the function. (can't think of an actual example).
I would love if you could provide me with a clearer example 😃
The text was updated successfully, but these errors were encountered:
But in your example I feel you do just the opposite.
I'm not sure I see why it's "opposite"?
I can definitely agree that there's more logic in the function with all those extra conditionals. But the point I'm actually making is that the more verbose and explicit logic is easier to trace through than the implicit "oops I already exited, none of this runs" kind of logic of early-return.
I think a nicer example to make your point would be edge cases, where dealing with the edge case before the main logic can make it harder to understand
This is an interesting point, but it could go both ways. Typically, I am more likely to appreciate an early-return in the case where it's the sole exception and where it's the very first thing in the function. What I dislike most is that early-return might be anywhere strewn throughout.
I think you make a very solid point in that section when you say that:
But in your example I feel you do just the opposite. You add an extra variable that I need to keep track just to know if I should still execute the code to come. You say that:
I am not saying that you are wrong when you say that returning too often can make the function harder to read, but I would argue that in this example you actually do have all those points where you do need to return.
I think a nicer example to make your point would be edge cases, where dealing with the edge case before the main logic can make it harder to understand what it is you are trying to achieve with the function. (can't think of an actual example).
I would love if you could provide me with a clearer example 😃
The text was updated successfully, but these errors were encountered: