<p>In packages/libraries the pointer name to the receiving struct is always different in each package. </p>
<p>Example:</p>
<pre><code>type data struct {
data interface{}
}
func (d *data)SomeThing(newDate interface{}) {
d.data = newData
}
type Animal struct {
name string
}
func (a *Animal)SetName(newName string) {
a.name = newName
}
</code></pre>
<p>In this example d is for *data and a for *Animal.
Why not always use the same name, for example this, as pointer to the receiving struct?</p>
<pre><code>type data struct {
data interface{}
}
func (this *data)SomeThing(newDate interface{}) {
this.data = newData
}
type Animal struct {
name string
}
func (this *Animal)SetName(name string) {
this.name = name
}
</code></pre>
<p>In a team and/or big software project, this would make things a lot more easier and simpler to understand.</p>
<p>Or is there any rule or reason not to do this? I can't find any stuff about that in Effective Go or somewhere else.</p>
<hr/>**评论：**<br/><br/>jere_jones: <pre><p>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 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. Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.</p>
<p>Source: <a href="https://github.com/golang/go/wiki/CodeReviewComments#receiver-names" rel="nofollow">https://github.com/golang/go/wiki/CodeReviewComments#receiver-names</a></p>
<p>However, that just said "don't do it" without a good reason. Having come from C++, using "this" seemed the most natural until I read this: <a href="https://blog.heroku.com/neither-self-nor-this-receivers-in-go" rel="nofollow">https://blog.heroku.com/neither-self-nor-this-receivers-in-go</a> I recommend giving it a read.</p></pre>Freakezoid: <pre><p>Thank you! The heroku post is a very good read and totally makes sense.</p></pre>dchapes: <pre><p>You might as well ask why not always call your function arguments <code>arg1</code>, <code>arg2</code>, etc? A method receiver is just a different way of writing the first argument (e.g. <code>func (a *Animal) Foo(x int)</code> is basically just <code>func Foo(a *Animal, x int)</code>) (<a href="https://play.golang.org/p/m4CaFyEfbn" rel="nofollow">example</a>).</p>
<p>Using <code>this</code> is not descriptive and bad; when you use a language that doesn't force you to use such useless identifiers you should be more descriptive. Of course given how such identifiers are used that <a href="http://research.swtch.com/names" rel="nofollow">doesn't mean it needs to be long to be more useful than <code>this</code></a>.</p>
<blockquote>
<p>I can't find any stuff about that in Effective Go or somewhere else.</p>
</blockquote>
<p><a href="https://github.com/golang/go/wiki/CodeReviewComments#receiver-names" rel="nofollow">https://github.com/golang/go/wiki/CodeReviewComments#receiver-names</a></p></pre>weberc2: <pre><p>Honestly I don't think it matters either way. Go chose this convention; Python, Java, etc, chose another. Both seem to work fine. I can't perceive any harm or benefit in either direction.</p></pre>barsonme: <pre><p>Except in other languages 'this' is different from Go's receivers. Go's receivers are syntactical sugar for the first argument; that is, </p>
<p><code>func (t T) Foo(t2 T2)</code></p>
<p>is essentially the same as:</p>
<p><code>func Foo(t T, t2 T2)</code></p>
<p>If you wrote this Java method:</p>
<p><code>public void Foo(T this)</code></p>
<p>people reviewing your code would take issue since 'this' is a completely nondescript name.</p>
<p>Plus, like I sort of mentioned above, calling the receiver 'this' implies that it's the same as 'this' in other languages---it's not. In JavaScript, for example, 'this' defaults to the global object (Go has no such thing); is undefined or the global object during a function call with and without strict mode, respectively; or, if it's an object method, it refers to the object the method is called on.</p>
<p>This is distinctly different from Go.</p>
<p>Write Go in Go. Don't try to write Java or JavaScript or Python.</p></pre>weberc2: <pre><ol>
<li>I agree that <code>this</code> and <code>self</code> in other languages are different from Go's receivers.</li>
<li>This doesn't change my mind that there would be no significant consequence had the Go developers used <code>this</code> or <code>self</code> as the convention instead.</li>
</ol></pre>johnbr: <pre><p>I always use this, haven't had a problem yet and I've written thousands of lines of go code with that idiom. Very curious if there's a subtle problem I've missed.</p></pre>xiegeo: <pre><p>You don't know what you are missing. </p>
<ul>
<li>You can search for a.foo or b.foo, where in a large code base there can be many more this.foo. Especially in Go where a method can be in any file. </li>
<li>Follow conventions mean it is easier for others to read your code and you to read others code. Please follow conventions, if you ever collaborate with others.</li>
<li>this is a keyword in other languages that does object oriented programing differently from Go. It act as a trigger word for me to change my programing model.</li>
</ul>
<p>You should remove all this from your .go files now, and train yourself a habit of writing idiomatic Go code. Otherwise you won't get the benefit of the above.</p></pre>natefinch: <pre><p>Don't use this or self or anything similar. It's uninformative. </p>
<pre><code>func Speak(a Animal)
</code></pre>
<p>Is the same as </p>
<pre><code>func (a Animal) Speak()
</code></pre>
<p>Literally the same, the latter is just syntactic sugar.</p>
<p>I hope you'd never write </p>
<pre><code>func Speak(this Animal)
</code></pre>
<p>So please don't do this:</p>
<pre><code>func (this Animal) Speak()
</code></pre>
<p>Also, it marks the code as unidiomatic, and raises red flags for people who have been coding in go for a long time. If the author ignored such an easy convention, what other conventions are being ignored?</p></pre>mdwhatcott: <pre><p>The name "a" isn't any more informative than "this". They send slightly different messages depending on your perspective.</p></pre>natefinch: <pre><p>It's slightly more informative, especially if you have multiple types with methods in the same file. Again, I would ask - would you name a function parameter this? If not, then don't name a receiver this. </p></pre>whizack: <pre><p>i would argue that you should still treat receiver variables like parameter names. if your convention is to name parameters long form names (animal *Animal), you should do so, if it's to use shorthand (a *Animal), then do so. </p>
<p>The idea is to treat them like parameters, so that when you refactor code, the locality of the type it is attached to doesn't matter. self.Speak(), for example, is specific to code attached to a struct that has a Speak method, not an animal with a Speak method</p></pre>weberc2: <pre><p>You're not missing anything, you're just deviating from the convention. People in this thread are getting religious about it and downvoting you (here, have an upvote). It's not a big deal, it's just a little annoying to look at for those of us who have acclimated to the Go convention. If you want your code to be a little more reader-friendly to Go programmers, avoid using <code>this</code> or <code>self</code>, but contrary to the impression given by other commenters it's not going to miraculously improve your productivity or make your algorithm O(1) or something.</p></pre>mdwhatcott: <pre><p>If using 'this' makes sense for you and your team, then use 'this'!</p></pre>mdwhatcott: <pre><p>No, there isn't any good reason not to use 'this', 'self' or other generic names. The only reason we are ever given is that it's simply not 'idiomatic' in go. Doing something just because it's been labeled idiomatic is idiotic. If it makes sense for your team to use 'this', then use it! I work at SmartyStreets (a predominantly Go shop for several years) where we use nothing but 'this' for receiver names unless there's really compelling reason to do otherwise. We've never felt hindered or regretted the decision. <a href="https://github.com/smartystreets" rel="nofollow">https://github.com/smartystreets</a></p></pre>jonbonazza: <pre><p>I'd argue that not being idiomatic is perfectly valid reason NOT to do something. Writing idiomatic code promotes consistency across code bases. This makes it easier for new developers to come up to speed on your projects and when developers leave your company, they will have an easier time getting up to speed on the code bases of their new gig. Code conventions are a real thing and should be adhered to as strictly as possible. While not necessarily enforced like standards, they still have very valid purposes and should not be scoffed at. I'd say your company is doing the entire Go community a disservice by not adhering to these conventions and I, for one, wouldn't be very happy working somewhere that doesn't understand this.</p></pre>natefinch: <pre><p>
