preface

In everyday development we define methods as well as functions. This is nothing, but some students who switch from PHP or other object-oriented languages to GO often name the receiver name as this, self, me, etc.

The author also met similar students in the actual project development, but repeatedly reminded them to no effect, so I decided to write this article in order to persuade them.

CR Standard Practice

First let’s take a look at GO’s recommended standard naming of Receiver Names. The following is an excerpt from github.com/golang/go/w…

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 gives the method a special meaning. 
In Go, the receiver of a method is just another parameter and therefore, should be named accordingly. 
...
Copy the code

The brief translation summary has the following two points:

  1. Method recipient names should reflect their identity and should not be usedme.this.selfTypical identifiers for these object-oriented languages.
  2. In GO, the method receiver is just another parameter to the method.

Receiver is the first parameter of the method!

The second point above may not be easy to understand, so let’s go straight to the following demo:

// T ...
type T int

// Println ...
func (t T) Println(a) {
	fmt.Println("value: %v", t)
}

func main(a) {
	t := T(1)
	t.Println()
	T.Println(t) // Receiver is used as the first parameter of the function. This occurs when the value is copied, so the t variable inside the method is only a copy of the real t variable. This is not the same as this
}
// output:
value: 1
value: 1
Copy the code

From the demo above, we know that the receiver can be passed directly to the method as the first argument. And t.println () is probably a grammatical sugar in Go.

At this point, some of you may be wondering, since Go provides this sugar, what’s wrong with naming it that way? Before I explain, let’s continue to see the following demo:

// Test ...
type Test struct {
	A int
}

// SetA ...
func (t Test) SetA(a int) {
	t.A = a
}

// SetA1 ...
func (t *Test) SetA1(a int) {
	t.A = a
}

func main(a) {
	t := Test{
		A: 3,
	}
	fmt.Println("demo1:")
	fmt.Println(t.A)
	t.SetA(5)
	fmt.Println(t.A)
	t1 := Test{
		A: 4,
	}
	fmt.Println("demo2:")
	fmt.Println(t1.A)
	(&t1).SetA1(6)
	fmt.Println(t1.A)
}
// output:
demo1:
3
3
demo2:
4
6
Copy the code

As we know from the demo above, SetA is called when receiver is not a pointer and the value does not change at all.

Since Go is all about value passing, if you name SetA’s Receiver this, self, etc., it loses its meaning — “to call a method on an object is to pass a message to that object”. And the properties of the object itself don’t necessarily change.

In conclusion, please do not use this, self and other names with special meanings when naming receiver.

Receiver can be nil!!

Recently, while reading up on H2_bundle. go, I came across a particular piece of code that made me break out in a cold sweat, so I’ll add it here to prevent myself and the rest of you from stepping into a pit.

A screenshot of the source code is as follows:

What surprised me was the part marked red in the picture, and the receiver even judged it as nil! In my subconscious mind, I always think so. Receiver has a value by default, and it can be used directly. This was so shocking that I wrote a demo to check it out:

type A struct {
	v int
}

func (a *A) test(a) {
	fmt.Println(a == nil)}func (a *A) testV(a) {
	fmt.Println(a.v)
}


func main(a) {
	var a *A
	a.test()
	a.testV()
}

Copy the code

The above output is as follows:

A.test () can output normally, but panic!! Is reported only when v is inside the variable structure. Fortunately, the Receiver is the first parameter of the method. Because it is the first argument, even if it is passed as nil, the function will be called normally, and panic will be reported where it is actually used.

In view of the fact that Receiver is so special, I specially added follow-up content after the completion of this article to remind myself and readers.

This section will be added on the evening of February 27, 2008.

Finally, I wish you every success in your career!

Welcome to pay attention to wechat public account and baijia account.

Hundred article address

Baijiahao.baidu.com/s?id=167507…