-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
proposal: wiki: CodeReviewComments change #37495
Comments
There are counter-examples to this rule:
And plenty more. Sometimes your rule makes some sense, and other times it does not. If anything the rule is: do what makes the code and docs clearest. This seems like a likely decline, since it is contrary to standard practice as evidenced by the standard library. |
If this gets declined, should close #37384 too. |
No change in consensus, so declined. |
Regarding this section:
https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters
There is an extra case that I thought of recently as I was writing a lot of functions that were taking functions with more than a single parameter and return value, and it a couple of things occurred to me, related to that section there:
If the function signature is only used once, put good suggested names in the signature where it appears inside the signature.
If the function signature is used in two or more places, it is suggested to define the function signature as a type, and put the nice parameter/return value names there.
It may seem trivial but it affects both readability and programmer-user experience. Closures in Go are already enforced (for what reason, I am not yet clear on, my guess is implementation and being a bit too macro-like) to be verbosely pasted in everywhere when they are populated with a function. Every time one is written there is a big ugly signature there to look at. If the parameters (at least) are not named, then it's very noisy, you get absolutely no information from looking at it, what it does, except, if it's there, the name of the parameter that is a function.
So the two guidelines above are my recommendation for adding to this document in relation to naming function parameters (and when used a lot, naming the signature itself using a type definition), mitigate some of the noise introduced by closure function signatures, and reduce the work required to use them - one can just jump to the function, jump to its named function signature, copy, add
{}
and start putting some code inside there.The text was updated successfully, but these errors were encountered: