Fast, configurable, extensible, flexible, and beautiful linter for Go. Drop-in replacement of golint. Revive
provides a framework for development of custom rules, and lets you define a strict preset for enhancing your development & code review processes.
Logo by Georgi Serev
Here's how revive
is different from golint
:
- Allows to enable or disable rules using a configuration file.
- Allows to configure the linting rules with a TOML file.
- 2x faster running the same rules as golint.
- Provides functionality for disabling a specific rule or the entire linter for a file or a range of lines.
golint
allows this only for generated files.
- Optional type checking. Most rules in golint do not require type checking. If you disable them in the config file, revive will run over 6x faster than golint.
- Provides multiple formatters which let us customize the output.
- Allows to customize the return code for the entire linter or based on the failure of only some rules.
- Everyone can extend it easily with custom rules or formatters.
Revive
provides more rules compared togolint
.
tidb
- TiDB is a distributed HTAP database compatible with the MySQL protocolgrafana
- The tool for beautiful monitoring and metric analytics & dashboards for Graphite, InfluxDB & Prometheus & Moreetcd
- Distributed reliable key-value store for the most critical data of a distributed systemcadence
- Cadence is a distributed, scalable, durable, and highly available orchestration engine by Uber to execute asynchronous long-running business logic in a scalable and resilient wayferret
- Declarative web scrapinggopass
- The slightly more awesome standard unix password manager for teamsgitea
- Git with a cup of tea, painless self-hosted git serviceexcelize
- Go library for reading and writing Microsoft Excelβ’ (XLSX) filesaurora
- aurora is a web-based Beanstalk queue server console written in Gosoar
- SQL Optimizer And Rewriterpyroscope
- Continuous profiling platformgorush
- A push notification server written in Go (Golang).dry
- dry - A Docker manager for the terminal.go-echarts
- The adorable charts library for Golangreviewdog
- Automated code review tool integrated with any code analysis tools regardless of programming languagerudder-server
- Privacy and Security focused Segment-alternative, in Golang and React.sklearn
- A partial port of scikit-learn written in Go.protoc-gen-doc
- Documentation generator plugin for Google Protocol Buffers.llvm
- Library for interacting with LLVM IR in pure Go.jenkins-library
- Jenkins shared library for Continuous Delivery pipelines by SAP.pd
- Placement driver for TiKV.shellhub
- ShellHub enables teams to easily access any Linux device behind firewall and NAT.lorawan-stack
- The Things Network Stack for LoRaWAN V3gin-jwt
- This is a JWT middleware for Gin framework.gofight
- Testing API Handler written in Golang.Beaver
- A Real Time Messaging Server.ggz
- An URL shortener service written in GolangCodeac.io
- Automated code review service integrates with GitHub, Bitbucket and GitLab (even self-hosted) and helps you fight technical debt.DevLake
- Apache DevLake is an open-source dev data platform to ingest, analyze, and visualize the fragmented data from DevOps toolsοΌwhich can distill insights to improve engineering productivity.
Open a PR to add your project.
- revive
go install github.com/mgechev/revive@latest
or get a released executable from the Releases page.
You can install the main branch (including the last commit) with:
go install github.com/mgechev/revive@master
Since the default behavior of revive
is compatible with golint
, without providing any additional flags, the only difference you'd notice is faster execution.
revive
supports a -config
flag whose value should correspond to a TOML file describing which rules to use for revive
's linting. If not provided, revive
will try to use a global config file (assumed to be located at $HOME/revive.toml
). Otherwise, if no configuration TOML file is found then revive
uses a built-in set of default linting rules.
A volume needs to be mounted to share the current repository with the container.
Please refer to the bind mounts Docker documentation
docker run -v "$(pwd)":/var/<repository> ghcr.io/mgechev/revive:v1.1.2-next -config /var/<repository>/revive.toml -formatter stylish ./var/kidle/...
-v
is for the volumeghcr.io/mgechev/revive:v1.1.2-next
is the image name and its version corresponding torevive
command- The provided flags are the same as the binary usage.
If you want to use revive with Bazel, take a look at the rules that Atlassian maintains.
- Support for VSCode in vscode-go.
- Support for GoLand via File Watchers.
- Support for Atom via linter-revive.
- Support for vim via dense-analysis/ale.
let g:ale_linters = {
\ 'go': ['revive'],
\}
- Revive Action with annotation support
Codeac.io - Automated code review service integrates with GitHub, Bitbucket and GitLab (even self-hosted) and helps you fight technical debt. Check your pull-requests with revive automatically. (free for open-source projects)
To enable revive
in golangci-lint
you need to add revive
to the list of enabled linters:
# golangci-lint configuration file
linters:
enable:
- revive
Then revive
can be configured by adding an entry to the linters-settings
section of the configuration, for example:
# golangci-lint configuration file
linters-settings:
revive:
ignore-generated-header: true
severity: warning
rules:
- name: atomic
- name: line-length-limit
severity: error
arguments: [80]
- name: unhandled-error
arguments : ["fmt.Printf", "myFunction"]
The above configuration enables three rules of revive
: atomic, line-length-limit and unhandled-error and pass some arguments to the last two.
The Configuration section of this document provides details on how to configure revive
. Note that while revive
configuration is in TOML, that of golangci-lint
is in YAML.
Please notice that if no particular configuration is provided, revive
will behave as go-lint
does, i.e. all go-lint
rules are enabled (the Available Rules table details what are the go-lint
rules). When a configuration is provided, only rules in the configuration are enabled.
revive
accepts the following command line parameters:
-
-config [PATH]
- path to config file in TOML format, defaults to$HOME/revive.toml
if present. -
-exclude [PATTERN]
- pattern for files/directories/packages to be excluded for linting. You can specify the files you want to exclude for linting either as package name (i.e.github.com/mgechev/revive
), list them as individual files (i.e.file.go
), directories (i.e../foo/...
), or any combination of the three. -
-formatter [NAME]
- formatter to be used for the output. The currently available formatters are:default
- will output the failures the same way thatgolint
does.json
- outputs the failures in JSON format.ndjson
- outputs the failures as stream in newline delimited JSON (NDJSON) format.friendly
- outputs the failures when found. Shows summary of all the failures.stylish
- formats the failures in a table. Keep in mind that it doesn't stream the output so it might be perceived as slower compared to others.checkstyle
- outputs the failures in XML format compatible with that of Java's Checkstyle.
-
-max_open_files
- maximum number of open files at the same time. Defaults to unlimited. -
-set_exit_status
- set exit status to 1 if any issues are found, overwriteserrorCode
andwarningCode
in config. -
-version
- get revive version.
revive -config revive.toml -exclude file1.go -exclude file2.go -formatter friendly github.com/mgechev/revive package/...
- The command above will use the configuration from
revive.toml
revive
will ignorefile1.go
andfile2.go
- The output will be formatted with the
friendly
formatter - The linter will analyze
github.com/mgechev/revive
and the files inpackage
Using comments, you can disable the linter for the entire file or only range of lines:
//revive:disable
func Public() {}
//revive:enable
The snippet above, will disable revive
between the revive:disable
and revive:enable
comments. If you skip revive:enable
, the linter will be disabled for the rest of the file.
With revive:disable-next-line
and revive:disable-line
you can disable revive
on a particular code line.
You can do the same on a rule level. In case you want to disable only a particular rule, you can use:
//revive:disable:unexported-return
func Public() private {
return private
}
//revive:enable:unexported-return
This way, revive
will not warn you for that you're returning an object of an unexported type, from an exported function.
You can document why you disable the linter by adding a trailing text in the directive, for example
//revive:disable Until the code is stable
//revive:disable:cyclomatic High complexity score but easy to understand
You can also configure revive
to enforce documenting linter disabling directives by adding
[directive.specify-disable-reason]
in the configuration. You can set the severity (defaults to warning) of the violation of this directive
[directive.specify-disable-reason]
severity = "error"
revive
can be configured with a TOML file. Here's a sample configuration with explanation for the individual properties:
# When set to false, ignores files with "GENERATED" header, similar to golint
ignoreGeneratedHeader = true
# Sets the default severity to "warning"
severity = "warning"
# Sets the default failure confidence. This means that linting errors
# with less than 0.8 confidence will be ignored.
confidence = 0.8
# Sets the error code for failures with severity "error"
errorCode = 0
# Sets the error code for failures with severity "warning"
warningCode = 0
# Configuration of the `cyclomatic` rule. Here we specify that
# the rule should fail if it detects code with higher complexity than 10.
[rule.cyclomatic]
arguments = [10]
# Sets the severity of the `package-comments` rule to "error".
[rule.package-comments]
severity = "error"
By default revive
will enable only the linting rules that are named in the configuration file.
For example, the previous configuration file makes revive
to enable only cyclomatic and package-comments linting rules.
To enable all available rules you need to add:
enableAllRules = true
This will enable all available rules no matter of what rules are named in the configuration file.
To disable a rule, you simply mark it as disabled in the configuration. For example:
[rule.line-length-limit]
Disabled = true
When enabling all rules you still need/can provide specific configurations for rules. The following files is an example configuration were all rules are enabled, with exception to those that are explicitly disabled, and some rules are configured with particular arguments:
severity = "warning"
confidence = 0.8
errorCode = 0
warningCode = 0
# Enable all available rules
enableAllRules = true
# Disabled rules
[rule.blank-imports]
Disabled = true
[rule.file-header]
Disabled = true
[rule.max-public-structs]
Disabled = true
[rule.line-length-limit]
Disabled = true
[rule.function-length]
Disabled = true
# Rule tuning
[rule.argument-limit]
Arguments = [5]
[rule.cyclomatic]
Arguments = [10]
[rule.cognitive-complexity]
Arguments = [7]
[rule.function-result-limit]
Arguments = [3]
[rule.error-strings]
Arguments = ["mypackage.Error"]
The default configuration of revive
can be found at defaults.toml
. This will enable all rules available in golint
and use their default configuration (i.e. the way they are hardcoded in golint
).
revive -config defaults.toml github.com/mgechev/revive
This will use the configuration file defaults.toml
, the default
formatter, and will run linting over the github.com/mgechev/revive
package.
revive -config config.toml -formatter friendly github.com/mgechev/revive
This will use config.toml
, the friendly
formatter, and will run linting over the github.com/mgechev/revive
package.
The following snippet contains the recommended revive
configuration that you can use in your project:
ignoreGeneratedHeader = false
severity = "warning"
confidence = 0.8
errorCode = 0
warningCode = 0
[rule.blank-imports]
[rule.context-as-argument]
[rule.context-keys-type]
[rule.dot-imports]
[rule.error-return]
[rule.error-strings]
[rule.error-naming]
[rule.exported]
[rule.if-return]
[rule.increment-decrement]
[rule.var-naming]
[rule.var-declaration]
[rule.package-comments]
[rule.range]
[rule.receiver-naming]
[rule.time-naming]
[rule.unexported-return]
[rule.indent-error-flow]
[rule.errorf]
[rule.empty-block]
[rule.superfluous-else]
[rule.unused-parameter]
[rule.unreachable-code]
[rule.redefines-builtin-id]
List of all available rules. The rules ported from golint
are left unchanged and indicated in the golint
column.
Name | Config | Description | golint |
Typed |
---|---|---|---|---|
context-keys-type |
n/a | Disallows the usage of basic types in context.WithValue . |
yes | yes |
time-equal |
n/a | Suggests to use time.Time.Equal instead of == and != for equality check time. |
no | yes |
time-naming |
n/a | Conventions around the naming of time variables. | yes | yes |
var-declaration |
n/a | Reduces redundancies around variable declaration. | yes | yes |
unexported-return |
n/a | Warns when a public return is from unexported type. | yes | yes |
errorf |
n/a | Should replace errors.New(fmt.Sprintf()) with fmt.Errorf() |
yes | yes |
blank-imports |
n/a | Disallows blank imports | yes | no |
context-as-argument |
n/a | context.Context should be the first argument of a function. |
yes | no |
dot-imports |
n/a | Forbids . imports. |
yes | no |
error-return |
n/a | The error return parameter should be last. | yes | no |
error-strings |
[]string | Conventions around error strings. | yes | no |
error-naming |
n/a | Naming of error variables. | yes | no |
exported |
[]string | Naming and commenting conventions on exported symbols. | yes | no |
if-return |
n/a | Redundant if when returning an error. | no | no |
increment-decrement |
n/a | Use i++ and i-- instead of i += 1 and i -= 1 . |
yes | no |
var-naming |
whitelist & blacklist of initialisms | Naming rules. | yes | no |
package-comments |
n/a | Package commenting conventions. | yes | no |
range |
n/a | Prevents redundant variables when iterating over a collection. | yes | no |
receiver-naming |
n/a | Conventions around the naming of receivers. | yes | no |
indent-error-flow |
n/a | Prevents redundant else statements. | yes | no |
argument-limit |
int | Specifies the maximum number of arguments a function can receive | no | no |
cyclomatic |
int | Sets restriction for maximum Cyclomatic complexity. | no | no |
max-public-structs |
int | The maximum number of public structs in a file. | no | no |
file-header |
string | Header which each file should have. | no | no |
empty-block |
n/a | Warns on empty code blocks | no | yes |
superfluous-else |
n/a | Prevents redundant else statements (extends indent-error-flow ) |
no | no |
confusing-naming |
n/a | Warns on methods with names that differ only by capitalization | no | no |
get-return |
n/a | Warns on getters that do not yield any result | no | no |
modifies-parameter |
n/a | Warns on assignments to function parameters | no | no |
confusing-results |
n/a | Suggests to name potentially confusing function results | no | no |
deep-exit |
n/a | Looks for program exits in funcs other than main() or init() |
no | no |
unused-parameter |
n/a | Suggests to rename or remove unused function parameters | no | no |
unreachable-code |
n/a | Warns on unreachable code | no | no |
add-constant |
map | Suggests using constant for magic numbers and string literals | no | no |
flag-parameter |
n/a | Warns on boolean parameters that create a control coupling | no | no |
unnecessary-stmt |
n/a | Suggests removing or simplifying unnecessary statements | no | no |
struct-tag |
n/a | Checks common struct tags like json ,xml ,yaml |
no | no |
modifies-value-receiver |
n/a | Warns on assignments to value-passed method receivers | no | yes |
constant-logical-expr |
n/a | Warns on constant logical expressions | no | no |
bool-literal-in-expr |
n/a | Suggests removing Boolean literals from logic expressions | no | no |
redefines-builtin-id |
n/a | Warns on redefinitions of builtin identifiers | no | no |
function-result-limit |
int | Specifies the maximum number of results a function can return | no | no |
imports-blacklist |
[]string | Disallows importing the specified packages | no | no |
range-val-in-closure |
n/a | Warns if range value is used in a closure dispatched as goroutine | no | no |
range-val-address |
n/a | Warns if address of range value is used dangerously | no | yes |
waitgroup-by-value |
n/a | Warns on functions taking sync.WaitGroup as a by-value parameter | no | no |
atomic |
n/a | Check for common mistaken usages of the sync/atomic package |
no | no |
empty-lines |
n/a | Warns when there are heading or trailing newlines in a block | no | no |
line-length-limit |
int | Specifies the maximum number of characters in a line | no | no |
call-to-gc |
n/a | Warns on explicit call to the garbage collector | no | no |
duplicated-imports |
n/a | Looks for packages that are imported two or more times | no | no |
import-shadowing |
n/a | Spots identifiers that shadow an import | no | no |
bare-return |
n/a | Warns on bare returns | no | no |
unused-receiver |
n/a | Suggests to rename or remove unused method receivers | no | no |
unhandled-error |
[]string | Warns on unhandled errors returned by funcion calls | no | yes |
cognitive-complexity |
int | Sets restriction for maximum Cognitive complexity. | no | no |
string-of-int |
n/a | Warns on suspicious casts from int to string | no | yes |
string-format |
map | Warns on specific string literals that fail one or more user-configured regular expressions | no | no |
early-return |
n/a | Spots if-then-else statements that can be refactored to simplify code reading | no | no |
unconditional-recursion |
n/a | Warns on function calls that will lead to (direct) infinite recursion | no | no |
identical-branches |
n/a | Spots if-then-else statements with identical then and else branches |
no | no |
defer |
map | Warns on some defer gotchas | no | no |
unexported-naming |
n/a | Warns on wrongly named un-exported symbols | no | no |
function-length |
n/a | Warns on functions exceeding the statements or lines max | no | no |
nested-structs |
n/a | Warns on structs within structs | no | no |
useless-break |
n/a | Warns on useless break statements in case clauses |
no | no |
banned-characters |
n/a | Checks banned characters in identifiers | no | no |
optimize-operands-order |
n/a | Checks inefficient conditional expressions | no | no |
use-any |
n/a | Proposes to replace interface{} with its alias any |
no | no |
datarace |
n/a | Spots potential dataraces | no | no |
Here you can find how you can configure some existing rules:
This rule accepts two slices of strings, a whitelist and a blacklist 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 identifier called customId
but will warn that customVm
should be called customVM
.
This section lists all the available formatters and provides a screenshot for each one.
The default formatter produces the same output as golint
.
The plain formatter produces the same output as the default formatter and appends URL to the rule description.
The unix formatter produces the same output as the default formatter but surrounds the rules in []
.
The sarif
formatter produces outputs 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.
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).
Each rule needs to implement the lint.Rule
interface:
type Rule interface {
Name() string
Apply(*File, Arguments) []Failure
}
The Arguments
type is an alias of the type []interface{}
. The arguments of the rule are passed from the configuration file.
Let's suppose we have developed a rule called BanStructNameRule
which disallow us to name a structure with given identifier. We can set the banned identifier by using the TOML configuration file:
[rule.ban-struct-name]
arguments = ["Foo"]
With the snippet above we:
- Enable the rule with name
ban-struct-name
. TheName()
method of our rule should return a string which matchesban-struct-name
. - Configure the rule with the argument
Foo
. The list of arguments will be passed toApply(*File, Arguments)
together with the target file we're linting currently.
A sample rule implementation can be found here.
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 own linter using revive
as linting engine.
The following code shows how to use revive
in your own 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/mgechev/revive/cli"
"github.com/mgechev/revive/lint"
"github.com/mgechev/revive/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 own cli:
package mylib
import (
"github.com/mgechev/revive/cli"
"github.com/mgechev/revive/revivelib"
"github.com/mgechev/revive/lint"
)
// 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 { ... }
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.
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:
time golint kubernetes/... > /dev/null
real 0m54.837s
user 0m57.844s
sys 0m9.146s
# 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 which 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.
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 REVIVE_FORCE_COLOR=1
to the environment you're running in. For example:
REVIVE_FORCE_COLOR=1 revive -formatter friendly ./... | tee revive.log
renovate[bot] | mgechev | chavacava | renovate-bot | xuri | doniacld |
Clivern | bernhardreisenberger | morphy2k | butuzov | dshemin | heynemann |
gsamokovarov | tymonx | sina-devel | abeltay | dvejmz | mihaitodor |
markelog | tamird | shmsr | mapreal19 | kulti | Aragur |
s0xzwasd | derekperkins | yangdiangzb | petethepig | euank | quasilyte |
grongor | jamesmaidment | jan-xyz | jefersonf | johnrichardrinehart | very-amused |
ldez | mathieu-aubin | michalhisim | pa-m | paul-at-start | weastur |
paco0x | rdeusser | ridvansumset | tartale | Jarema | vkrol |
cce | haya14busa | jmckenzieark | techknowlogick | zeripath |
MIT