Inconsistency of message types and json keys in modules #3669
Labels
T: State Machine Breaking
State machine breaking changes (impacts consensus).
Type: Code Hygiene
General cleanup and restructuring of code to provide clarity, flexibility, and modularity.
Milestone
@jackzampolin Here is a list of message types registered in the modules.
x/bank
x/distributions
x/gov
x/slashing
x/staking
x/ibc
Some of them have "Msg" as prefix and some of them not while types in IBC have it as suffix. It looks like there is a convention that when you register concrete type, you put the type string the same as the struct but this is not the case as you have
cdc.RegisterConcrete(MsgDelegate{}, "cosmos-sdk/MsgDelegate", nil)
butcdc.RegisterConcrete(MsgUndelegate{}, "cosmos-sdk/Undelegate", nil)
. It will be easier to follow if you can keep a naming convention.Another inconsistency is in the JSON keys. Some of them are using
address
and some of them areaddr
. This can be found in thex/staking
module. The keys increate_validator
aredelegator_address
andvalidator_address
but indelegate
they aredelegator_addr
andvalidator_addr
.This also make the tags a little bit hard to follow. When there are
delegator_addr
andvalidator_addr
in the tx message, the tags would bedelegator
,source-validator
,destination-validator
, etc.It will be great if these terms can be in consistence following a convention.
The text was updated successfully, but these errors were encountered: