You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are places where things could be simplified, written a bit more clearly, methods that are a bit too long with high cognitive complexity, making them a bit hard to interpret, such as:
`x/gasless/keeper/fee_helper.go - size and cognitive complexity of methods should be reduced
x/gasless/keeper/store.go - handling the closing of the iterator, such as in IterateAllTxGTIDs should be done simply by defer iter.Close()
there are places where slices are initialized as literals. we should avoid this
x/gasless/keeper/store.go/UpdateConsumerAllowance - Is this meant to update all the consumers with matching gasTank.Id? In that case the method should be named something like UpdateConsumerAllowances. Also, there are multiple places where consumptions are iterated to find the one with matching gasTank.Id. There should be a method for that.
There should be more unit tests across the module.
Potential future functionalities
Currently we can only have one fee denom per gas tank. It would be nice to remove that restriction in the future.
Another limitation is the possibility of having only one message per transaction. That can also be a bit restricting
The text was updated successfully, but these errors were encountered:
Technical debt in x/gasless
There are places where things could be simplified, written a bit more clearly, methods that are a bit too long with high cognitive complexity, making them a bit hard to interpret, such as:
x/gasless/keeper/store.go
- handling the closing of the iterator, such as inIterateAllTxGTIDs
should be done simply bydefer iter.Close()
x/gasless/keeper/store.go/UpdateConsumerAllowance
- Is this meant to update all the consumers with matchinggasTank.Id
? In that case the method should be named something likeUpdateConsumerAllowances
. Also, there are multiple places where consumptions are iterated to find the one with matchinggasTank.Id
. There should be a method for that.There should be more unit tests across the module.
Potential future functionalities
The text was updated successfully, but these errors were encountered: