vint

vint

Very fast linter for Golang. Designed to be MUCH FASTER replacement of golangci-lint and support as much rules as possible.

Here's how vint is different from golangci-lint:

• More than 7x faster running the same rules as golangci-lint.
• Clear centralized unified configuration.

This is still in progress, docs are not updated and in need of some cleanup, but vint already has close to 500 rules supported and benchmarks show quite well performance.

Installation

TBD

Usage

TBD

Command Line Flags

TBD

Sample Invocations

TBD

Comment Directives

TBD

Custom Configuration

TBD

Rule-level file excludes

TBD

'legacy' Revive rules

List of all available rules. The rules ported from golint are left unchanged and indicated in the golint column.

Configurable rules

Here you can find how you can configure some existing rules. Rule configuration options are documented using the kebab-case format (e.g., max-lit-count, allow-strs, skip-comments), and this format is preferred. For backward compatibility, camelCase (e.g., maxLitCount, allowStrs, skipComments) and lowercase (e.g., maxlitcount, allowstrs, skipcomments) formats are still supported but are deprecated.

var-naming

This rule accepts two slices of strings, an allowlist and a blocklist of initialisms. By default, the rule behaves exactly as the alternative in golint but optionally, you can relax it (see golint/lint/issues/89)

[rule.var-naming]
arguments = [["ID"], ["VM"]]

This way, revive will not warn for an identifier called customId but will warn that customVm should be called customVM.

Available Formatters

This section lists all the available formatters and provides a screenshot for each one.

Friendly

Stylish

Default

The default formatter produces the same output as golint.

Plain

The plain formatter produces the same output as the default formatter and appends the URL to the rule description.

Unix

The unix formatter produces the same output as the default formatter but surrounds the rules in [].

JSON

The json formatter produces output in JSON format.

NDJSON

The ndjson formatter produces output in Newline Delimited JSON format.

Checkstyle

The checkstyle formatter produces output in a Checkstyle-like format.

SARIF

The sarif formatter produces output in SARIF, for Static Analysis Results Interchange Format, a standard JSON-based format for the output of static analysis tools defined and promoted by OASIS.

Current supported version of the standard is SARIF-v2.1.0.

Extensibility

The tool can be extended with custom rules or formatters. This section contains additional information on how to implement such.

To extend the linter with a custom rule you can push it to this repository or use revive as a library (see below)

To add a custom formatter you'll have to push it to this repository or fork it. This is due to the limited -buildmode=plugin support which works only on Linux (with known issues).

Writing a Custom Rule

See DEVELOPING.md for instructions on how to write a custom rule.

Using revive as a library

If a rule is specific to your use case (i.e. it is not a good candidate to be added to revive's rule set) you can add it to your linter using revive as a linting engine.

The following code shows how to use revive in your application. In the example only one rule is added (myRule), of course, you can add as many as you need to. Your rules can be configured programmatically or with the standard revive configuration file. The full rule set of revive is also actionable by your application.

package main

import (
	"github.com/vint-go/vint/cli"
	"github.com/vint-go/vint/lint"
	"github.com/vint-go/vint/revivelib"
)

func main() {
	cli.RunRevive(revivelib.NewExtraRule(&myRule{}, lint.RuleConfig{}))
}

type myRule struct{}

func (f myRule) Name() string {
	return "myRule"
}

func (f myRule) Apply(*lint.File, lint.Arguments) []lint.Failure {
	// ...
}

You can still go further and use revive without its CLI, as part of your library, or your CLI:

package mylib

import (
	"github.com/vint-go/vint/config"
	"github.com/vint-go/vint/lint"
	"github.com/vint-go/vint/revivelib"
)

// Error checking removed for clarity
func LintMyFile(file string) {
	conf, _ := config.GetConfig("../defaults.toml")

	revive, _ := revivelib.New(
		conf, // Configuration file
		true, // Set exit status
		2048, // Max open files

		// Then add as many extra rules as you need
		revivelib.NewExtraRule(&myRule{}, lint.RuleConfig{}),
	)

	failuresChan, err := revive.Lint(
		revivelib.Include(file),
		revivelib.Exclude("./fixtures"),
		// You can use as many revivelib.Include or revivelib.Exclude as required
	)
	if err != nil {
		panic("Shouldn't have failed: " + err.Error())
	}

	// Now let's return the formatted errors
	failures, exitCode, _ := revive.Format("stylish", failuresChan)

	// failures is the string with all formatted lint error messages
	// exit code is 0 if no errors, 1 if errors (unless config options change it)
	// ... do something with them
}

type myRule struct{}

func (f myRule) Name() string {
	return "myRule"
}

func (f myRule) Apply(*lint.File, lint.Arguments) []lint.Failure {
	// ...
}

Custom Formatter

Each formatter needs to implement the following interface:

type Formatter interface {
	Format(<-chan Failure, Config) (string, error)
	Name() string
}

The Format method accepts a channel of Failure instances and the configuration of the enabled rules. The Name() method should return a string different from the names of the already existing rules. This string is used when specifying the formatter when invoking the revive CLI tool.

For a sample formatter, take a look at this file.

Speed Comparison

Compared to golint, revive performs better because it lints the files for each individual rule into a separate goroutine. Here's a basic performance benchmark on MacBook Pro Early 2013 run on Kubernetes:

golint

$ time golint kubernetes/... > /dev/null

real    0m54.837s
user    0m57.844s
sys     0m9.146s

revive's speed

# no type checking
$ time revive -config untyped.toml kubernetes/... > /dev/null

real    0m8.471s
user    0m40.721s
sys     0m3.262s

Keep in mind that if you use rules that require type checking, the performance may drop to 2x faster than golint:

# type checking enabled
$ time revive kubernetes/... > /dev/null

real    0m26.211s
user    2m6.708s
sys     0m17.192s

Currently, type-checking is enabled by default. If you want to run the linter without type-checking, remove all typed rules from the configuration file.

Overriding colorization detection

By default, revive determines whether or not to colorize its output based on whether it's connected to a TTY or not. This works for most use cases, but may not behave as expected if you use revive in a pipeline of commands, where STDOUT is being piped to another command.

To force colorization, add VINT_FORCE_COLOR=1 to the environment you're running in. For example:

VINT_FORCE_COLOR=1 revive -formatter friendly ./... | tee revive.log

Open a PR to add your project.

Contributors

Credits

This project is a fork of revive and contains all its original code and rules, with the addition of rules reproducing the behavior of these linters:

License

MIT