style!: Refactor codebase to use proper Interface prefixes

[Olshansk]

Description

Closes: #13254

Per the discussion and examples in #13254, this aims to make the Cosmos SDK more compliant with Golang syntax best practices.

Changes

Specifically, naming interface with either an I prefix or an Interface suffix rather than an I suffix. The interfaces renamed are:

• s/ValidatorI/IValidator
• s/HasAnimalI/IHasAnimal
• s/MsgSubmitEvidenceI/IMsgSubmitEvidence
• s/DelegationI/IDelegation
• s/FeeAllowanceI/IFeeAllowance
• s/ModuleAccountI/IModuleAccount
• s/AccountKeeperI/IAccountKeeperI
• s/AccountI/IAccount

How Changes were made

1. All relevant interface were found using VSCode's regex and case match for: type (.*)[a-z]I Interface \{
2. The following two regex find and replace all was made for each interface (Account is an example):

Find: AccountI([^a-z^A-z])
Replace: IAccount$1

Find: AccountI$
Replace: Account

References

1. Interface naming convention in Golang:

2. Dave Cheney's Practical Go:

---

Author Checklist

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[Olshansk]

@alexanderbez The only thing I did to verify is running make test. Should that be enough given the details here?

[julienrbrt]

Can you move that under the API Breaking Changes section (l.107)?

[Olshansk]

Done. Note that I was following the instructions in https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pull-requests and figured someone (in the future) is responsible from moving it from Unreleased to API Breaking.

[julienrbrt]

Let's apply the correct .md formatting here too. (When you use the markdown all in one vscode extension, it unfortunately generates a ToC that does not respect the markdownlint config. You need to ctrl+z and ctrl+k+ctrl+s for reverting the formatting)

[Olshansk]

Yea, Visual Studio's "Markdown all in one" doesn't play well with "MarkdownLint". I ended up just checking out all of my .md changes and updating it manually.

[codecov]

Codecov Report

Merging #13268 (99ba23a) into main (4fe7797) will decrease coverage by 0.22%.
The diff coverage is 6.66%.

❗ Current head 99ba23a differs from pull request most recent head 83009d6. Consider uploading reports for the commit 83009d6 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13268      +/-   ##
==========================================
- Coverage   55.87%   55.65%   -0.23%     
==========================================
  Files         646      712      +66     
  Lines       54895    60840    +5945     
==========================================
+ Hits        30675    33862    +3187     
- Misses      21762    24162    +2400     
- Partials     2458     2816     +358     

Impacted Files	Coverage Δ
baseapp/abci.go	67.01% <0.00%> (+2.59%)	⬆️
baseapp/baseapp.go	77.12% <ø> (+0.25%)	⬆️
baseapp/grpcrouter.go	90.00% <ø> (ø)
baseapp/grpcrouter_helpers.go	25.00% <ø> (ø)
baseapp/grpcserver.go	1.72% <ø> (ø)
baseapp/msg_service_router.go	85.29% <ø> (+4.41%)	⬆️
baseapp/options.go	69.23% <ø> (+0.71%)	⬆️
client/account_retriever.go	0.00% <ø> (ø)
client/cmd.go	57.73% <0.00%> (ø)
client/context.go	54.49% <0.00%> (-1.79%)	⬇️
... and 260 more

[amaury1093]

This is a huge API breaking change IMO, for all chains. With time I got used to AccountI. I also don't see a strong need to switch (just because some guy wrote about it in a medium article?)

I'm fine with eventually switching to something consistent, but maybe let's do it in 2 phases:

1. Add type aliases, e.g. AccountI -> IAccount, so that everything is backwards-compatible. Add deprecation godoc on all old interfaces.
2. Rip off the old interfaces, but probably not in 0.47

[Olshansk]

This is a huge API breaking change IMO, for all chains

Agreed.

I also don't see a strong need to switch

Yea, I was conflicted as well so I made sure to double-check if I should proceed before making any changes: #13254 (comment)

(just because some guy wrote about it in a medium article?)

It seems to be the "Go" standard. I can find more references and added them to the PR. Just lmk if I should invest the time

Add type aliases, e.g. AccountI -> IAccount, so that everything is backwards-compatible. Add deprecation godoc on all old interfaces.

Done. See #13279

Here's an example:

Rip off the old interfaces, but probably not in 0.47

Could you leave a comment in #13279 on next steps and timelines?

[aaronc]

I appreciate your efforts here @Olshansk and I know we're not really treating the SDK as 1.0 yet so some breaking changes are okay.

At the same time, I think we really need to measure the value of breaking changes like this. I generally think changing things just because some authority says the style should be different isn't a great reason to force downstream changes on clients...

So my preference would generally for us not to be spending time on these sort of changes (and then forcing our users to spend time on them), if there isn't some larger benefit.

AccountI, etc. may seem clunky but it also seems like not a big deal...

[Olshansk]

Understood.

I confirmed the scope of work before starting in the original tickets, tended to the comments in the PR, documented the future work, tested the changes, and made it backwards compatible with the goal of better code health before the SDK reaches 1.0

If you still believe I should close out the PR and issue without a merge, please lmk.

[aaronc]

The aliases address backwards compatibility. Also if its an issue for downstream users, we don't have to remove them for 1.0

@AmauryM @marbar3778 what do you think?

[alexanderbez]

So you mean you defined new proto types? Or just aliases? Idk...just seems like such a large diff and tech debt to maintain for a version just to change type names.

[Olshansk]

I implemented the approach @AmauryM suggested in the first message in this thread.

Given the long async back and forth, is there a cosmos contributor hour where we can discuss it over a call?

[Olshansk]

@AmauryM Could you take a look at the latest changes and see if it aligns with your suggestion?

[amaury1093]

My personal take is that this PR sees a lot of resistance, and doesn't have a clear motivation from SDK users (i.e. no-one came to us about AccountI vs IAccount).

@Olshansk I really appreciate your work here, but my recommendation would be to simply to close the PR. I'm sorry about this, we should have better discussed this in the issue beforehand.

However, if you feel strongly about this going through, please join the SDK community call this Thursday 6-7pm CEST, and we can quickly discuss this with a wider audience before moving forward.

[Olshansk]

Will do!

[tac0turtle]

closing this for now but let me know if you'd like to attend the community call to discuss further.

[Olshansk]

closing this for now but let me know if you'd like to attend the community call to discuss further.

I would! When is the next one?

[peterbourgon]

Idiomatic Go interfaces are named by their method set, and are never prefixed or suffixed by I or Interface.

By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.

There are a number of such names and it's productive to honor them and the function names they capture. Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion, don't give your method one of those names unless it has the same signature and meaning. Conversely, if your type implements a method with the same meaning as a method on a well-known type, give it the same name and signature; call your string-converter method String not ToString.

https://go.dev/doc/effective_go#interface-names

[Olshansk]

@peterbourgon Really appreciate the link & reference (and somewhat embarrassed I didn't find that link myself). Let's close this out.