Receiver Name Consistency

[bnunamak]

There is a lint rule enforced by lintReceiverNames that specifies that receivers should be named consistently.

Generally this is a sound assumption, but I would like to argue against the general application of this rule.

Consider the following (common) use-case:

There is a struct that one would like to chain functions on. It is defined as follows:

type Node struct{
	Value string
	Prev *Node
	Next *Node
}

I would like to define the following functions on this node:

func (p *Node) Chain(v string) *Node {
	n := &Node{Value: v}
	n.Prev = p
	p.Next = n
	return n
}

func (n *Node) Empty() bool{
	return n.Value == ""
}

For the Chain function, the passed Node receiver is semantically equal to the previous node, whereas the Empty function is applied directly to a current node. Thus, it is desirable to name the pointer receivers differently, so that p can always be interpreted as the current node.

The lint rule defined in lintReceiverNames goes directly against this. It is difficult to detect semantic differences like the above example, however it should be possible to possible ignore this rule for "chaining" methods, where another instance of the same type is returned.

I would like to hear your thoughts before investing any time into this, if there is a general consensus on this topic I would open a PR.

[ianlancetaylor]

I think the general lint rule is sound.

By all means ignore the lint warning if it doesn't apply to your code. Lint rules are meant to be generally applicable, but they are not meant to be 100% applicable.

[bnunamak]

@ianlancetaylor Unfortunately I don't want to ignore lint rules, as they pollute my IDE with warnings, and make real code inconsistencies less transparent.

It seems that this is a more general issue with golint that has been discussed in depth in #263. I will explore community-supported lint tools as a workaround. Thanks!