Cosmos-sdk: Getter functions format

[sunnya97]

Related to PR #505

So according to Effective Go, getter functions should not be prefixed with Get.
https://golang.org/doc/effective_go.html#Getters

However, throughout the codebase, we have numerous instances of using the prefix. It is even in our interface standards (example: https://github.com/cosmos/cosmos-sdk/blob/master/types/account.go#L10).

We should choose one paradigm and stick to it.

Note: I am personally a fan of Get prefix.

@ethanfrey @adrianbrink @rigelrozanski

[adrianbrink]

@jaekwon @ebuchman What do you think?

[ethanfrey]

For Get() and Set(), I agree, there is no other way.

I also think Coins() and SetCoins() reads better....
It makes the accessor look more like reading a field.

The exception is if there was already a public field called Coins.
However, if you have Coins() and SetCoins() there is no reason to make the field public, and can name it coins.

One example of the above is protobuf auto-generated code that will create a field called Coins and an accessor GetCoins(), but we try to stay away from protobuf generated code in this codebase, right?

[mossid]

I think name collision is the reason we are prefixing getters. For example ValidatorSet has method GetPower, GetOwner, etc, because most of the structs those implement ValidatorSet has already Power, Owner, ... as their field vars.

[rigelrozanski]

hmm I wonder. Would that really cause a collision? Generally if you are referencing an interface we don't by default automatically access the variables of the underlying struct right? - Only the interface functions

[mossid]

Golang doesn't even allow to declare field and method with the same name since they share the same namespace. I agree we can make the field unexported so make it accepted by the compiler, but once we do that we have to enforce people to write the field unexported if they are used by methods. If it is not a big problem, then we can remove Get prefixes.

[rigelrozanski]

Oh you're totally write, the underlying struct wouldn't be able to define the field and function with the same name. For marshalling purposes I think we often want to keep name exported.

I'm closing for now until there is some compelling new pattern which we want to implement