Skip to content
This repository has been archived by the owner on Sep 1, 2018. It is now read-only.

mvdan/interfacer

master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
 
 

interfacer

GoDoc Build Status

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
}