Skip to content

Ch2 - Early Returns example seems misleading #155

Open
@tiagojdf

Description

@tiagojdf

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 😃

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions