Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ch2 - Early Returns example seems misleading #155

Open
tiagojdf opened this issue Feb 27, 2018 · 2 comments
Open

Ch2 - Early Returns example seems misleading #155

tiagojdf opened this issue Feb 27, 2018 · 2 comments

Comments

@tiagojdf
Copy link

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 😃

@getify
Copy link
Owner

getify commented May 16, 2018

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.

@getify
Copy link
Owner

getify commented May 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants