Don't use me, this, self as receiver names

[dlsniper]

From https://github.com/golang/go/wiki/CodeReviewComments#receiver-names

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. 

[zolotov]

Fixed in #2583

[zolotov]

Following is still actual

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").

[daliborfilus]

I was just baffled by this in IntelliJ. Of course I want to use these generic names, such as "self". I don't want to look at methods of all structs and wonder where that "c" or "cl" comes from. Using "self" is self explanatory, it provides clear information what we are talking to and where it comes from and is simple to use, simple to remember.

IMO this is such a stupid recommendation from go devs. I understand that this plugin just follows recommendations from go devs, so I got nothing against you guys, but boy is this stupid. I will just turn off this inspection for everything and move on.

By the way, other part of their recommendations say opposite of this: do not use single letter variables, such as x, i, j, k... and now they recommend "c" for client? What the...

// end of rant.

[zolotov]

@NoICE I don't agree with this recommendation too. Anyway it's unknown when this will be implemented and it's totally going to be disableable, so nothing worry about

[dlsniper]

I'm sorry but this is how golint (or go vet) works currently. The inspection should follow that to be on par with the other tools / editors. You can still disable if you don't like it, as @zolotov said.

[daliborfilus]

@zolotov I searched for this issue/commit because it already warned me about that, so it must be already live.

@dlsniper I understand that it's not fault of this plugin but you guys just implemented something that is required because of something beyond your control. You did a good thing, if this is go's official recommendation and go vet warns about it too.

[dlsniper]

@NoICE see: https://github.com/golang/go/wiki/CodeReviewComments#receiver-names

[tmilev]

I do not agree with this Go language recommendation either. The recommendation is bad in my opinion: for example because it alienates developers such as myself.

For example, the arbitrary abbreviations used in golang (func instead of function) would not pass my code review. However, even though I think that abbreviations such as "func" are very poor style, I would not allow myself to dictate non-necessary guidelines to my peers.

P.S. I comment here with the hope that the golang developers will read this.

[dlsniper]

@tmilev this tracker is abandoned. If you are are using IntelliJ IDEA Ultimate with the Go plugin, or GoLand, then you can follow the discussion at the official tracker: https://youtrack.jetbrains.com/issue/GO-2158

Also, it is highly unlikely that the Go developers will ever read the comment from here. Please feel free to open an issue at the official tracker https://golang.org/issues/new

[aitounejjar]

Let's not forget about the other naming recommendation that I think is applicable to most computer languages: the length and expressiveness of a variable should correlate with its scope. E.g.: if a variable's scope is limited to say a 3-liner control structure, then you can shorten its name as you see fit, but if it's a global variable then you go verbose with its name.

The scope of a receiver argument can potentially span several line of code, depending on the function in question of course. Combine this with the other recommendation that receiver argument's name shall be consistent, and there you have it.

In my modest opinion, I'd rather see func (robot *Robot) ... or even func (this *Robot) over func (r *Robot).

[s0xzwasd]

@aitounejjar please see: https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/2158#issuecomment-415927649