Skip to content
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: remove guideline against 'this' / 'self' receiver names #38550

mappu opened this issue Apr 21, 2020 · 3 comments


Copy link

@mappu mappu commented Apr 21, 2020

The page at has this to say about receiver names for struct methods:

Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that gives the method a special meaning. In Go, the receiver of a method is just another parameter and therefore, should be named accordingly.

This explanation was added in #28475.

But I don't believe this is a good argument:

  • C++, Python, and Lua all have identical semantics as Go here
    • This includes the behaviour when calling methods on null this pointers; and
    • casting to a function with an extra parameter ("just another parameter")
  • The rest of the paragraph describes how to bypass this rule by creating an equally generic name, by taking some single letters of the type name - that is a needless impediment to good refactoring

In fact, there are benefits to using self/this:

  • Normalised name for identical concept as other languages
    • reduces friction in polyglot codebases
    • improves onboarding speed for new Go developers
  • Simplifies automated porting

I am interested in removal of this blessed guideline as a first prerequisite towards removing this as a default lint rule in vet and in other tools.

(However, I would support a vet rule enforcing that the names this/self are only used with pointer receivers, for the same reasons above.)

@gopherbot gopherbot added this to the Proposal milestone Apr 21, 2020
@gopherbot gopherbot added the Proposal label Apr 21, 2020
Copy link

@networkimprov networkimprov commented Apr 21, 2020

I've always felt an added burden when reading method code which doesn't use a predictable receiver name. Especially as you need to see clearly where a method alters its object's state.

Worse still when the name is one letter among other single-letter names!

Copy link

@ianlancetaylor ianlancetaylor commented Apr 21, 2020

The wiki page is a style guideline, and as it says the Go style is not to use names like self or this for method receivers.

I believe that the explanation is accurate. At least in C++, virtual methods are special, and the name this has a special meaning: it refers to the real object with virtual methods attached, not to the object whose type appears in the method. Go doesn't have virtual methods, and the method receiver is always the exact type shown in the receiver.

If you want to write code that uses a different style, go ahead. You can also simply ignore the associated lint errors.

Copy link

@dpinela dpinela commented Apr 21, 2020

The current style guideline has the advantage of internal consistency: the naming convention for a parameter is the same whether or not it's the receiver. This makes sense to me, since in Go the receiver behaves no differently from other parameters.

Also for what it's worth, I've had substantial experience with both Python and C++ and I still prefer the Go style. It feels odd now to name all method receivers the same, even ones of completely unrelated types.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants