The wiki page states that naked returns are bad but does not give any reasons _why_ they are bad.
In general, I think naked returns are a good idea in almost all cases. Using naked returns consistently enforces a discipline that the variables to be returned will always be correct if the function returns right then. This makes it easier to follow the flow of a function, since Ctrl+F (or equivalent in your text editor) for the return param names will find all the critical pieces.
This may not be correct, but it's enough to warrant a better explanation of why naked returns are bad.
/cc @andybons
The doc never states naked returns are “bad.” It states that explicit return values are preferred for functions longer than a few lines (and that naming return values isn’t always the best for clarity of docs).
@dmitshur’s comment on the proposal for removing naked returns sums up one of the reasons why they can be problematic.
How would you like us to improve the wording?
It states that explicit return values are preferred
This is the same thing as saying bare returns are bad. And it gives no justification for it.
The linked comment is a good argument against supporting variables which are scoped to sub-functional blocks, but not an argument against bare returns. As he says himself, he rarely uses them, so he forgot they existed and couldn't parse a function using them.
Personally, I'd prefer they were mandatory, which would solve his problem and have the discipline and readability benefits I mentioned in the top-level issue.
Sorry, but we aren't going to make naked returns mandatory. In practice, use of them in large functions causes legitimate readability issues. Our advice is that you can avoid shadowing surprises by being explicit with your return values.
If that's true, you could provide examples. I am skeptical you can.
On Thu, Jun 20, 2019, 08:43 Andrew Bonventre notifications@github.com
wrote:
Sorry, but we aren't going to make naked returns mandatory. In practice,
use of them in large functions causes legitimate readability issues. Our
advice is that you can avoid shadowing surprises by being explicit with
your return values.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/32672?email_source=notifications&email_token=AAJR7Z6YQV7VDYTNNNGIESTP3OQR3A5CNFSM4HZCXMOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFZRVI#issuecomment-504076501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJR7ZY7GZPHMLPCG6GVYZTP3OQR3ANCNFSM4HZCXMOA
.
Most helpful comment
Sorry, but we aren't going to make naked returns mandatory. In practice, use of them in large functions causes legitimate readability issues. Our advice is that you can avoid shadowing surprises by being explicit with your return values.