Go: wiki: CodeReviewComments#NamedResultParameters

[jkopczyn]

On the other hand, [...] if the meaning of a result isn't clear from context, adding names may be useful in some contexts.

In general, this will almost always be true. Humans are extremely bad at assessing how obvious an inference is if they already know the fact to be inferred. This is a special case of the illusion of transparency. In general, the meaning of a result isn't clear from context even if it feels to the author like it's extremely clear from context.

Because of this, the advice given in this section is harmful in most cases.

[mvdan]

If this were true, then most funcs in godoc pages would be confusing, as one wouldn't be able to tell what each result parameter is for. In practice, I don't think that's true.

If you argue that people tend to take the easy route and name result parameters slightly less often than they should, perhaps I'd agree there. But that's entirely different from the wiki advice being harmful.

[jkopczyn]

In my experience it is absolutely true in practice. Godoc pages are mostly
devoid of usable information unless they have details in docstrings.

On Tue, Jun 18, 2019, 15:15 Daniel Martí [e-mail] wrote:

If this were true, then most funcs in godoc pages would be confusing, as
one wouldn't be able to tell what each result parameter is for. In
practice, I don't think that's true.

If you argue that people tend to take the easy route and name result
parameters slightly less often than they should, perhaps I'd agree there.
But that's entirely different from the wiki advice being harmful.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/32671?email_source=notifications&email_token=AAJR7Z3ITJW4RETJMOMDGRDP3FM67A5CNFSM4HZCUHD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYADVHY#issuecomment-503331487,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJR7Z4WPLQ7K7REIYX5R3LP3FM67ANCNFSM4HZCUHDQ
.

[agnivade]

@andybons @dmitshur

[andybons]

Thanks for the suggestion.

Naming the result parameter doesn’t make the following function more clear:

func TrimSpace(s string) string

The accompanying godoc is sufficient enough to further understand what the function is doing.

Sorry, but the advice in the wiki page will remain as is. We don’t want to encourage people to use named return values all the time.

[jkopczyn]

You didn't actually engage with my point. Sure, in tiny one-result functions there are some where named returns don't help. That doesn't mean the majority or even plurality of functions are places where named returns are unhelpful.

[mvdan]

@jkopczyn you're saying that most functions require named result parameters to not be confusing, and you were given a simple counter-example - I think that's a fair reply. After all, you haven't given one example of a real function that's confusing because it lacks names.

If you want to prove your point, consider backing it up with data. For example, take a few std packages, count the ratio of functions that use named parameters, and give examples of functions with unnamed parameters that are confusing.

[jkopczyn]

No, that's not what I said. Most functions are more confusing if they leave
the returns unnamed; this is supported by the rational prior from
psychology.
Good docstrings can compensate for this, and the standard library largely
has good docstrings. Its functions would still be easier to understand if
they defaulted to naming their return values.

On Wed, Jun 19, 2019, 23:45 Daniel Martí [e-mail] wrote:

@jkopczyn https://github.com/jkopczyn you're saying that most functions
require named result parameters to not be confusing, and you were given a
simple counter-example - I think that's a fair reply. After all, you
haven't given one example of a real function that's confusing because it
lacks names.

If you want to prove your point, consider backing it up with data. For
example, take a few std packages, count the ratio of functions that use
named parameters, and give examples of functions with unnamed parameters
that are confusing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/32671?email_source=notifications&email_token=AAJR7Z2KIWBGJZGT2RIDMRTP3MRQDA5CNFSM4HZCUHD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYEN7AQ#issuecomment-503897986,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJR7Z6Z7KMPHXNSEJ3TOKLP3MRQDANCNFSM4HZCUHDQ
.

[mvdan]

Sorry, but this is still hard to follow without any data or examples. You also mention that good godoc strings can help here, but your original suggestion seems to leave them out of the equation.

Note that I don't have a strong opinion here, other than not wanting to encourage general use of named result parameters.