-1

Why people use only one character to represent the current instance in method of struct? Example:

type Something struct {}

func (s *Something) doSomething() {}

I find more readable to use:

func (something *Something) doSomething() {}
Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Amanda Ferrari
  • 1,168
  • 5
  • 17
  • 30
  • 7
    So use the latter? The former is only convention -- it doesn't matter syntactically. The real answer is that writing `func (leftHandedFrobnicatingFoobarer *LeftHandedFrobnicatingFoobarer) SomeMethod() { ... }` a bunch is a pain. – Adam Smith Sep 20 '18 at 03:25
  • 1
    It depends on your convenience if you want to give it a readable name. Or if its your code and no one is going to work on that then you can skip the whole name. – Himanshu Sep 20 '18 at 03:27
  • 5
    Two characters like in `st SomeThing` are common too. But these are methods on Something and Go isn't childish like Java where you repeat Something over and over again. If you are consistent than it is pretty clear that s is the receiver of all methods on *Something. – Volker Sep 20 '18 at 03:27
  • I would advise you to read the following documents (in the order presented): ["How to write Go code"](https://golang.org/doc/code.html), ["Effective Go"](https://golang.org/doc/effective_go.html?), ["Package names"](https://blog.golang.org/package-names), [Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments). That should equip you with the necessary knowledge about how to name things. – kostix Sep 20 '18 at 20:31
  • [See also](https://stackoverflow.com/q/23482068/720999). – kostix Sep 20 '18 at 20:32

1 Answers1

3

It's just good practice to follow rule that name should be short and concise (more info).
Also the point here is to avoid a way long names and generic names such as "me", "this" or "self" (more info).

cn007b
  • 16,596
  • 7
  • 59
  • 74
  • 1
    @amanda-ferrari, precisely what [Vladimir referred to](https://github.com/golang/go/wiki/CodeReviewComments#receiver-names). (Note that he did not mention that, but the document is actually a set of rules to write "core" Go code, which many consider to be _the_ Go style guide.) I would cite the most relevant bit from there: «The name need not be as descriptive as that of a method argument, as its role is obvious and serves no documentary purpose. It can be very short as it will appear on almost every line of every method of the type; familiarity admits brevity.» – kostix Sep 20 '18 at 20:25
  • @amanda-ferrari, in other words, if you're writing a method for the type named `Something`, you perfectly know from the context that the receiver variable of that method _is_ `Something`, and that variable usually gets referred to the most in any type's method (if it isn't, it's a good sign the method might be better converted into a standalone function). Hence referring to that receiver using some "long" name merely creates stuttering for no real gain. – kostix Sep 20 '18 at 20:28