You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.
This is true regardless of the size of the function which shows that the size of the function isn’t the determinant
Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don’t know how you could even say otherwise.
Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn’t, just guarded by if conditions - and these conditions any reader would have to keep in mind.
When a reader comes across an early return, that’s a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.
I never said longer functions are not less clear. I said my argument is valid irrespective of the length of the function which shows that the problems I claim multiple returns bring are independent of function length. 😊
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave if the validation fails nearly the same, they have to glance that the scope ends at the end of the function. Looks at conditional - that’s validation, looks at the nested block - everything here runs only after validation, looks after the block - a return. As I mentioned in another comment, validation is a trivial case to do either way. Returns inside business logic past validation is where the problematic bugs of this class show up which requires more thorough reading to avoid.
If you gave me a PR with early returns only during validation, I probably won’t ask you to rewrite it. If I see them further down, it’s not going in.
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave the validation behind just the same.
And that conditional indents your entire function one level - if you have more validation checks, that’s one level of indentation per check (or a complicated condition, depends whether you can validate it all in one place). It’s pretty much the case the other user illustrated above.
Returns inside business logic past validation is where the problematic bugs of this class show up
That much we agree. But again, this is not an early return issue, putting too much logic in a function is the issue. Rewriting it without early returns won’t make it much clearer. Creating other functions to handle different scenarios will.
Again, if you can write it with conditionals and returns, you can write it with equivalent number of conditionals and a single nested scope. No further scopes are needed. The conditional will even look nearly identically.
You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.
Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don’t know how you could even say otherwise.
Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn’t, just guarded by if conditions - and these conditions any reader would have to keep in mind.
When a reader comes across an early return, that’s a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.
I never said longer functions are not less clear. I said my argument is valid irrespective of the length of the function which shows that the problems I claim multiple returns bring are independent of function length. 😊
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave if the validation fails nearly the same, they have to glance that the scope ends at the end of the function. Looks at conditional - that’s validation, looks at the nested block - everything here runs only after validation, looks after the block - a return. As I mentioned in another comment, validation is a trivial case to do either way. Returns inside business logic past validation is where the problematic bugs of this class show up which requires more thorough reading to avoid.
If you gave me a PR with early returns only during validation, I probably won’t ask you to rewrite it. If I see them further down, it’s not going in.
And that conditional indents your entire function one level - if you have more validation checks, that’s one level of indentation per check (or a complicated condition, depends whether you can validate it all in one place). It’s pretty much the case the other user illustrated above.
That much we agree. But again, this is not an early return issue, putting too much logic in a function is the issue. Rewriting it without early returns won’t make it much clearer. Creating other functions to handle different scenarios will.
Again, if you can write it with conditionals and returns, you can write it with equivalent number of conditionals and a single nested scope. No further scopes are needed. The conditional will even look nearly identically.