Poorly chosen receiver name SCC-ST1006
Anti-pattern
Minor
10 days ago
—
3 years old
receiver name should not be an underscore, omit the name if it is unused
405}
406
407// InterceptUpgraded .
408func (_ *TestP2P) InterceptUpgraded(network.Conn) (allow bool, reason control.DisconnectReason) {409 return true, 0
410}
receiver name should not be an underscore, omit the name if it is unused
400}
401
402// InterceptSecured .
403func (_ *TestP2P) InterceptSecured(network.Direction, peer.ID, network.ConnMultiaddrs) (allow bool) {404 return true
405}
406receiver name should not be an underscore, omit the name if it is unused
395}
396
397// InterceptAccept .
398func (_ *TestP2P) InterceptAccept(_ network.ConnMultiaddrs) (allow bool) {399 return true
400}
401receiver name should not be an underscore, omit the name if it is unused
390}
391
392// InterceptAddrDial .
393func (_ *TestP2P) InterceptAddrDial(peer.ID, multiaddr.Multiaddr) (allow bool) {394 return true
395}
396receiver name should not be an underscore, omit the name if it is unused
385}
386
387// InterceptPeerDial .
388func (_ *TestP2P) InterceptPeerDial(peer.ID) (allow bool) {389 return true
390}
391
Description
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.
Bad practice
type something int
func (this something) foo() {}
Recommended
type something int
func (s something) foo() {}