fix(docs,code): correct spelling and grammar across comments, tests, and documentation (#25172)

Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>

client/keys/rename_test.go

@@ -50,7 +50,7 @@ func Test_runRenameCmd(t *testing.T) {
 	cmd.SetArgs([]string{fakeKeyName1, invalidName, fmt.Sprintf("--%s=%s", flags.FlagKeyringDir, kbHome)})
 	require.ErrorContains(t, cmd.ExecuteContext(ctx), "the new name cannot be empty or consist solely of whitespace")
 
-	// rename a key 'blah' which doesnt exist
+	// rename a key 'blah' which doesn't exist
 	cmd.SetArgs([]string{"blah", "blaah", fmt.Sprintf("--%s=%s", flags.FlagKeyringDir, kbHome)})
 	err = cmd.ExecuteContext(ctx)
 	require.Error(t, err)
@@ -100,7 +100,7 @@ func Test_runRenameCmd(t *testing.T) {
 	require.NoError(t, err)
 	require.Equal(t, oldAddr, renamedAddr)
 
-	// try to rename key1 but it doesnt exist anymore so error
+	// try to rename key1 but it doesn't exist anymore so error
 	cmd.SetArgs([]string{
 		fakeKeyName1,
 		fakeKeyName2,

crypto/keyring/keyring_test.go

@@ -1973,14 +1973,14 @@ func TestRenameKey(t *testing.T) {
 			},
 		},
 		{
-			name: "cant rename a key that doesnt exist",
+			name: "can't rename a key that doesn't exist",
 			run: func(kr Keyring) {
 				err := kr.Rename("bogus", "bogus2")
 				require.Error(t, err)
 			},
 		},
 		{
-			name: "cant rename a key to an already existing key name",
+			name: "can't rename a key to an already existing key name",
 			run: func(kr Keyring) {
 				key1, key2 := "existingKey", "existingKey2" // create 2 keys
 				newKeyRecord(t, kr, key1)
@@ -1991,7 +1991,7 @@ func TestRenameKey(t *testing.T) {
 			},
 		},
 		{
-			name: "cant rename key to itself",
+			name: "can't rename key to itself",
 			run: func(kr Keyring) {
 				keyName := "keyName"
 				newKeyRecord(t, kr, keyName)

docs/docs/build/building-modules/00-intro.md

@@ -56,7 +56,7 @@ https://github.com/cosmos/cosmos-sdk/blob/61da5d1c29c16a1eb5bb5488719fde604ec07b
 While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them:
 
 * **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-cosmos-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./06-keeper.md).
-* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../docs/learn/advanced/10-ocap.md) of the Cosmos SDK.
+* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be reused in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../docs/learn/advanced/10-ocap.md) of the Cosmos SDK.
 * **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some modules to be malicious. That is why module developers need to carefully think not only about how their module interacts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](./06-keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`.
 
 ## Main Components of Cosmos SDK Modules

docs/spec/fee_distribution/f1_fee_distr.tex

@@ -104,13 +104,13 @@ The solution here is to instead store each period created by a slash in the vali
 Then when withdrawing, you must iterate over all slashes between when you started and ended.
 Suppose you delegated at period $0$, a y\% slash occurred at period $2$, and your withdrawal creates period $4$.
 Then you receive funds from periods $0$ to $2$ as normal.
-The equations for funds you receive for periods $2$ to $4$ now uses $(1 - y)x$ for your stake instead of just $x$ stake.
+The equations for funds you receive for periods $2$ to $4$ now use $(1 - y)x$ for your stake instead of just $x$ stake.
 When there are multiple slashes, you just account for the accumulated slash factor.
 
 In practice this will not really be an efficiency hit, as the number of slashes is expected to be 0 or 1 for most validators.
 Validators that get slashed more will naturally lose their delegators.
 A malicious validator that gets itself slashed many times would increase the gas to withdraw linearly, but the economic loss of funds due to the slashes is expected to far out-weigh the extra overhead the honest withdrawer must pay for due to the gas.
-(TODO: frame that above sentence in terms of griefing factors, as thats more correct)
+(TODO: frame that above sentence in terms of griefing factors, as that's more correct)
 
 \subsection{Inflation}
 Inflation is the idea that we want every staked coin to create more staking tokens as time progresses.

internal/testutil/cmd.go

@@ -15,7 +15,7 @@ import (
 // **Warning**: this is only compatible with following flag types:
 //  1. the implementations of pflag.Value
 //  2. the built-in implementations of pflag.SliceValue
-//  3. the custom implementatons of pflag.SliceValue that are split by comma ","
+//  3. the custom implementations of pflag.SliceValue that are split by comma ","
 //
 // see https://github.com/spf13/cobra/issues/2079#issuecomment-1870115781 for more detail info
 func ResetArgs(t *testing.T, cmd *cobra.Command) {

server/start.go

@@ -679,7 +679,7 @@ func InPlaceTestnetCreator(testnetAppCreator types.AppCreator) *cobra.Command {
 		Short: "Create and start a testnet from current local state",
 		Long: `Create and start a testnet from current local state.
 After utilizing this command the network will start. If the network is stopped,
-the normal "start" command should be used. Re-using this command on state that
+the normal "start" command should be used. Reusing this command on state that
 has already been modified by this command could result in unexpected behavior.
 
 Additionally, the first block may take up to one minute to be committed, depending

store/cachekv/store.go

@@ -303,7 +303,7 @@ func (store *Store) dirtyItems(start, end []byte) {
 	n := len(store.unsortedCache)
 	unsorted := make([]*kv.Pair, 0)
 	// If the unsortedCache is too big, its costs too much to determine
-	// whats in the subset we are concerned about.
+	// what's in the subset we are concerned about.
 	// If you are interleaving iterator calls with writes, this can easily become an
 	// O(N^2) overhead.
 	// Even without that, too many range checks eventually becomes more expensive

store/cachekv/store_test.go

@@ -91,7 +91,7 @@ func TestCacheKVStoreNested(t *testing.T) {
 	require.Equal(t, valFmt(1), st.Get(keyFmt(1)))
 	require.Equal(t, valFmt(3), st2.Get(keyFmt(1)))
 
-	// st2 writes to its parent, st. doesnt effect mem
+	// st2 writes to its parent, st. doesn't effect mem
 	st2.Write()
 	require.Equal(t, []byte(nil), mem.Get(keyFmt(1)))
 	require.Equal(t, valFmt(3), st.Get(keyFmt(1)))
@@ -238,13 +238,13 @@ func TestCacheKVMergeIteratorBasics(t *testing.T) {
 	st.Write()
 	assertIterateDomain(t, st, 0)
 
-	// add two keys and assert theyre there
+	// add two keys and assert they're there
 	k1, v1 := keyFmt(1), valFmt(1)
 	st.Set(k, v)
 	st.Set(k1, v1)
 	assertIterateDomain(t, st, 2)
 
-	// write it and assert theyre there
+	// write it and assert they're there
 	st.Write()
 	assertIterateDomain(t, st, 2)
 

testutil/network/network.go

@@ -639,7 +639,7 @@ func New(l Logger, baseDir string, cfg Config) (*Network, error) {
 
 	l.Log("started test network at height:", height)
 
-	// Ensure we cleanup incase any test was abruptly halted (e.g. SIGINT) as any
+	// Ensure we cleanup in case any test was abruptly halted (e.g. SIGINT) as any
 	// defer in a test would not be called.
 	trapSignal(network.Cleanup)
 

types/router.go

@@ -4,6 +4,6 @@ import (
 	"regexp"
 )
 
-// IsAlphaNumeric defines a regular expression for matching against alpha-numeric
+// IsAlphaNumeric defines a regular expression for matching against alphanumeric
 // values.
 var IsAlphaNumeric = regexp.MustCompile(`^[a-zA-Z0-9]+$`).MatchString

x/authz/README.md

@@ -96,7 +96,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/types/authz.go#L
 
 In order to prevent DoS attacks, granting `StakeAuthorization`s with `x/authz` incurs gas. `StakeAuthorization` allows you to authorize another account to delegate, undelegate, or redelegate to validators. The authorizer can define a list of validators they allow or deny delegations to. The Cosmos SDK iterates over these lists and charge 10 gas for each validator in both of the lists.
 
-Since the state maintaining a list for granter, grantee pair with same expiration, we are iterating over the list to remove the grant (incase of any revoke of particular `msgType`) from the list and we are charging 20 gas per iteration.
+Since the state maintaining a list for granter, grantee pair with same expiration, we are iterating over the list to remove the grant (in case of any revoke of particular `msgType`) from the list and we are charging 20 gas per iteration.
 
 ## State
 

x/epochs/keeper/epoch.go

@@ -13,7 +13,7 @@ func (k *Keeper) GetEpochInfo(ctx sdk.Context, identifier string) (types.EpochIn
 }
 
 // AddEpochInfo adds a new epoch info. Will return an error if the epoch fails validation,
-// or re-uses an existing identifier.
+// or reuses an existing identifier.
 // This method also sets the start time if left unset, and sets the epoch start height.
 func (k *Keeper) AddEpochInfo(ctx sdk.Context, epoch types.EpochInfo) error {
 	err := epoch.Validate()

x/feegrant/migrations/v2/keys.go

@@ -24,7 +24,7 @@ var (
 // Key format:
 // - <0x01><exp_bytes><len(grantee_address_bytes)><grantee_address_bytes><len(granter_address_bytes)><granter_address_bytes>
 func FeeAllowancePrefixQueue(exp *time.Time, granterAddrBz []byte) []byte {
-	// no need of appending len(exp_bytes) here, `FormatTimeBytes` gives const length everytime.
+	// no need of appending len(exp_bytes) here, `FormatTimeBytes` gives const length every time.
 	var key []byte
 	key = append(key, FeeAllowanceQueueKeyPrefix...)
 	key = append(key, sdk.FormatTimeBytes(*exp)...)

x/gov/types/v1/params.go

@@ -192,13 +192,13 @@ func (p Params) ValidateBasic() error {
 
 	minInitialDepositRatio, err := sdkmath.LegacyNewDecFromStr(p.MinInitialDepositRatio)
 	if err != nil {
-		return fmt.Errorf("invalid mininum initial deposit ratio of proposal: %w", err)
+		return fmt.Errorf("invalid minimum initial deposit ratio of proposal: %w", err)
 	}
 	if minInitialDepositRatio.IsNegative() {
-		return fmt.Errorf("mininum initial deposit ratio of proposal must be positive: %s", minInitialDepositRatio)
+		return fmt.Errorf("minimum initial deposit ratio of proposal must be positive: %s", minInitialDepositRatio)
 	}
 	if minInitialDepositRatio.GT(sdkmath.LegacyOneDec()) {
-		return fmt.Errorf("mininum initial deposit ratio of proposal is too large: %s", minInitialDepositRatio)
+		return fmt.Errorf("minimum initial deposit ratio of proposal is too large: %s", minInitialDepositRatio)
 	}
 
 	proposalCancelRate, err := sdkmath.LegacyNewDecFromStr(p.ProposalCancelRatio)

x/nft/keeper/nft_batch_test.go

@@ -58,7 +58,7 @@ func (s *TestSuite) TestBatchMint() {
 			true,
 		},
 		{
-			"faild with repeated nft",
+			"failed with repeated nft",
 			func(tokens []nft.NFT) {
 				s.saveClass(tokens)
 			},
@@ -70,7 +70,7 @@ func (s *TestSuite) TestBatchMint() {
 			false,
 		},
 		{
-			"faild with not exist class",
+			"failed with not exist class",
 			func(tokens []nft.NFT) {
 				// do nothing
 			},
@@ -82,7 +82,7 @@ func (s *TestSuite) TestBatchMint() {
 			false,
 		},
 		{
-			"faild with exist nft",
+			"failed with exist nft",
 			func(tokens []nft.NFT) {
 				s.saveClass(tokens)
 				idx := rand.Intn(len(tokens))

x/upgrade/README.md

@@ -91,7 +91,7 @@ If there's a planned upgrade and the upgrade height is reached, the old binary w
 
 This information is critical to ensure the `StoreUpgrades` happens smoothly at correct height and
 expected upgrade. It eliminates the chances for the new binary to execute `StoreUpgrades` multiple
-times everytime on restart. Also if there are multiple upgrades planned on same height, the `Name`
+times every time on restart. Also if there are multiple upgrades planned on same height, the `Name`
 will ensure these `StoreUpgrades` takes place only in planned upgrade handler.
 
 ### Proposal