On the closest thing Golang has to a style guide found here, under Receiver Names this is written:

The name of a method's receiver should be a reflection of its identity; often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client"). Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions. The name need not be as descriptive as a that of a method argument, as its role is obvious and serves no documentary purpose.

I personally have always just used "this" as the identifier because "this" is the focus of what I am working on when I write and edit the function. It sounds right, and (to me at least) it makes sense.

If the name need not be descriptive, it's role is obvious, and it serves no documentary purpose, why would the use of "this" be frowned upon?


We'd have to ask the author of that style guide to know for sure, but I think the main reason I kind of agree with him is that the connection between struct and method is much looser in Go than other languages.

In essence, when you write a method like this:

func (m *MultiShape) area() float64 {

That's almost exactly the same thing as writing a function like this:

func area(m *MultiShape) float64 {

The only difference is a slight syntax change in how we call the function/method.

In other languages the this/self/whatever variable typically has some special properties such as being magically provided by the language, or having special access to private methods (remember Go doesn't have private fields/methods). Though the "receiver" is still being "magically provided" to some extent, it's so similar to a regular function argument it arguably doesn't count.

Plus, in "traditional" OOP languages a struct/class' methods all come with the struct/class definition, such that no more can be added from outside. In Go, as far as I know anyone can add more methods to anything (within the scope of their own code, of course).

I haven't written enough Go to make my own style guide, but personally I'd probably use this in methods defined in the same file as the struct they receive, and some more descriptive receiver name on methods that I attach to structs from other files.

  • That's a good explanation, I suppose I'm used to C# and other OOP languages so I'm reverting to conventions I know. – Adam Jun 11 '15 at 8:23
  • 1
    @Adam I would avoid this if for no other reason than to remind myself that I'm not in a traditional OOP language. – Michael Hampton Jul 9 '16 at 0:03
  • 4
    There is no real difference between "this" and "receiver" (and please stop abusing word "magic" - every feature of a high level programming language can be called "magic", this doesn't make it anything negative, your attempt to pick on "this" for being "magic" makes no sense). – mvmn Jul 5 '17 at 14:04
  • @mvmm Extreme care and diligence needs to be taken though in explaining magic to someone who is not familiar with it. It is not by chance witches used to be burned by the stake. – Zyl Feb 19 at 13:23

I am not convinced by this style guide and I don't think anything is better than this, me or self. Because this, me or self makes it super clear that the variable is an instance of the context struct. I'm not saying a lower cased struct name variable is a bad idea, I just like the way that this makes it super clear.

  • without an explanation, this answer may become useless in case if someone else posts an opposite opinion. For example, if someone posts a claim like "I am convinced by this style guide and I think it is better than this, me or self", how would this answer help reader to pick of two opposing opinions? Consider editing it into a better shape, to meet How to Answer guidelines – gnat Dec 26 '16 at 5:05
  • I think I have clearly explained what I wanted to say. – Qian Chen Jan 10 '18 at 7:55
  • 1
    I agree. I think there are too many brains poisoned by the javascript context. If you put that aside. That this refers to the current context is much simpler. And easier if you rename structs later on, or copy paste part of an implementation. Gong for short cryptic names line h. l. etc does not make it any easier than this. – Sentient Jun 8 '18 at 15:37

This is from a perspective of JavaScript where this has actual keyword meaning to the compiler, but from my understanding, if they're okay with two-letter abbreviations for the object type, it should be easy enough to use that instead. The reason for the difference is that in a decently-large block of progressively deeper asynchronous code, it could be very easy to misinterpret what "this", or the receiver, is in a deeper context; and it's possible it won't be the same object.

In JavaScript for instance, a control module might start up a dialog and declare an onLoad function inline for it. But at that point, it could be very easy for another coder to misinterpret this inside onLoad to refer to the control module, not the dialog; or vice versa. This could be avoided if the control were referred to as ctrl and the dialog as dg.

  • 3
    I'm not the downvoter, but most of the confusing behaviors of this in Javascript simply do not apply to Go, so I'm guessing that's why. – Ixrec Jun 10 '15 at 16:21
  • @Ixrec Hm...okay. I was kind of trying to extend it to situations where you could choose this's name; for instance, often JS coders will write var self = this to keep the same reference around; but according to Go's design guide, that could then have the same confusion issues, and theoretically should use a more descriptive reference. – Katana314 Jun 10 '15 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.