search

NibiruChain / nibiru

Nibiru Chain: The breakthrough smart contract platform ushering in the next era of money. Nibiru powers an ecosystem of dApps including perps, RWAs, and more.
https://nibiru.fi
Apache License 2.0
179 stars 200 forks source link

refactor: Use the module name rather than naming all of the exported packages ".../types" #1866

Open Unique-Divine opened 2 months ago

Unique-Divine commented 2 months ago

Context

In older Cosmos-SDK versions, it was common to import the publicly exposed types from a module by adding a "types" suffix to the package name. For example, 

import (
  banktypes "github.com/cosmos/cosmos-sdk/x/bank/types"
  devgastypes "github.com/NibiruChain/nibiru/x/devgas/v1/types"
)

Task List

[Expand Task Menu] - [ ] refactor(devgas): For #1866 - [ ] refactor(evm): For #1866 - [ ] refactor(epochs): For #1866 - [ ] refactor(genmsg): For #1866 - [ ] refactor(inflation): For #1866 - [ ] refactor(oracle): For #1866 - [ ] refactor(sudo): For #1866 - [ ] refactor(tokenfactory): For #1866

Implications

  1. This means that the true package name, "types", has to be overwritten with an alias for each import. The Golang LSP (what your IDE understands) still considers all of the packages as having the name "types", so your IDE will only suggest variables if you start typing "types". You can't just type "banktypes" in a new file and see code suggestions.

  2. When you use types from two modules at the same time or read code from within a module, you'll see a nonsemantic prefix, "types" everywhere. Essentially, package namespacing becomes irrelevant with this approach.

Suggestion

Follow the pattern of the nibiru/eth and nibiru/x/evm packages (also the convention from v0.50 of the Cosmos-SDK) by using the top-level package of a module for its types.

In other words, use bank.MsgSend instead of types.MsgSend or banktypes.MsgSend.

Support Points:

  1. Less namespace collisions: The module namespace is often completely unused aside from one place, which is the top-level "app" directory.

  2. IDEs become more useful: You can type a module's name and have your IDE automatically suggest its types

  3. Less aliasing: Using an alias for every import produces a bad code smell (opinionated take).

    "Using a generic name makes it easy to accidentally use the wrong value in a different file" - [Uber Golang Style Guide]

    I'd argue that this argument holds for imports and not just for other variables.