interfacer alternatives and similar packages
Based on the "Code Analysis" category.
Alternatively, view interfacer alternatives based on common mentions on social networks and blogs.
-
Go Metalinter
DISCONTINUED. Metalinter is a tool to automatically apply all static analysis tool and report their output in normalized form. -
revive
🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint -
go-cleanarch
Clean architecture validator for go, like a The Dependency Rule and interaction between packages in your Go projects. -
go-mod-outdated
Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates. -
goreturns
A gofmt/goimports-like tool for Go programmers that fills in Go return statements with zero values to match the func return types -
usestdlibvars
A linter that detect the possibility to use variables/constants from the Go standard library. -
staticcheck
staticcheck is go vet on steroids, applying a ton of static analysis checks you might be used to from tools like ReSharper for C#. -
Golint online
Lints online Go source files on GitHub, Bitbucket and Google Project Hosting using the golint package. -
blanket
blanket is a tool that helps you catch functions which don't have direct unit tests in your Go packages.
SaaSHub - Software Alternatives and Reviews
Do you think we are missing an alternative of interfacer or a related project?
README
interfacer
Deprecated: A tool that suggests interfaces is prone to bad suggestions, so its usefulness in real code is limited. This tool will remain available as a proof of concept, and for others to examine and learn from.
A linter that suggests interface types. In other words, it warns about the usage of types that are more specific than necessary.
go get -u mvdan.cc/interfacer
Note that this linter's suggestions tend to be subjective, as interfaces are not always the better option. You should select the proposed changes that make sense in your codebase, instead of following all of them blindly.
Usage
func ProcessInput(f *os.File) error {
b, err := ioutil.ReadAll(f)
if err != nil {
return err
}
return processBytes(b)
}
$ interfacer ./...
foo.go:10:19: f can be io.Reader
Basic idea
This tool inspects the parameters of your functions to see if they fit an interface type that is less specific than the current type.
The example above illustrates this point. Overly specific interfaces
also trigger a warning - if f
were an io.ReadCloser
, the same
message would appear.
It suggests interface types defined both in the func's package and the package's imports (two levels; direct imports and their direct imports).
False positives
To avoid false positives, it never does any suggestions on functions that may be implementing an interface method or a named function type.
It also skips parameters passed by value (excluding pointers and interfaces) on unexported functions, since that would introduce extra allocations where they are usually not worth the tradeoff.
Suppressing warnings
If a suggestion is technically correct but doesn't make sense, you can still suppress the warning by mentioning the type in the function name:
func ProcessInputFile(f *os.File) error {
// use as an io.Reader
}