All of these are fine opinions to hold. I don't begrudge you them and you
can write your code however you prefer.
But this is how I would respond if we where working on the same code.
On Tue, Oct 4, 2022 at 10:27 PM Richard Haven <richardcha...@gmail.com>
wrote:
> Apart from fulfilling interfaces, function receives are just another
> parameter, right?
>
> "In Go, the receiver of a method is just another parameter and therefore,
> should be named accordingly"
>
> I agree and it inspires me to name receivers well, not to name them more
> cryptically than other parameters. I am not in favour of using 'this' as a
> parameter name; I am in favour of using a word instead of a letter. Code
> should read easily and not require a cross-reference to know what "j" and
> "rer" mean
>
I agree that receivers should not be named any more cryptically. But I also
don't believe they should be named any more verbosely.
The main place a parameter name matters isn't the function body (you can
always introduce a new name as a local variable via `speakingName := n`, if
need be), but the signature appearing in the documentation. That's the
guiding star and those signatures should not stutter and they should be
clear.
For an `io.Reader` I might use "body", to make clear it is the body of an
HTTP request, or if there are multiple arguments of the same type. Or I
might use `r`, if it is clear from context what the reader is - e.g.
`zip.NewReader(r io.Reader)`. I *never* use "reader", though - `reader
io.Reader` never carries more useful information than `r io.Reader`, but it
is more text which adds more visual noise and takes more time to parse
mentally.
The same goes for receivers. And, personally, I can't really think of any
case where a receiver needs any speaking name to make the documentation
clear. The receiver is what you operate on. That's almost always enough
context to understand its meaning. So there's rarely a point to use more
than one letter.
As for slavishly using the same parameter name for all methods of a
> receiver, I refer the reader to Emerson. If a parameter, even a receiver,
> has a specific meaning for a method, then its name should match that
> meaning *even if it has a different name and meaning in a different
> method*. Go haughtily discards classes and instances, yet this foolish
> consistency clings to the single name of the struct unto which all receives
> must cleave. Parameter names should serve us, not the other way around
>
There's a lot of unnecessarily judgmental language here ("slavish",
"haughtily", "foolish"…), in my opinion. Just as a side-note.
The convention of using consistent receiver names meshes with the previous
point. You say that using a single letter is cryptic and you have to think
about what that letter means. Choosing the same name every time actually
helps with that. It means that if people jump around your code, from method
to method, they *don't* have to think a lot about what that letter means -
because for their entire exploration, that short name just means "the
receiver".
The only case where this hindrance comes up is thus when you jump between
contexts, methods of different types or functions and methods. That's fair
enough, but IMO a small price to pay for the benefits.
> Naming things is hard and it is important. Avoiding the difficulties of
> that task by hiding behind what someone, even the Go gods, have written is
> laziness
>
You are ascribing motivation to people in a doubtful way. I don't know many
people who do things just because the Go designers said so. Most people I
know do those things because a) they agree with the arguments of the Go
designers and b) they believe that *any* convention is better than no
convention. I certainly believe both.
Dismissing people's ability to make their own judgments just because you
disagree with them is pretty limiting to the kinds of discussions you will
have.
>
> I welcome responses
>
> Cheers
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a0e04e42-5c09-4ccb-8b8b-9a894b8195d2n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/a0e04e42-5c09-4ccb-8b8b-9a894b8195d2n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF1VX%2Bvz-2%3DCn975bEtgfjzLSfT1qG-ttDN2RZyxaWKQA%40mail.gmail.com.
