revive

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.

<p align="center"> <img src="./assets/logo.png" alt="" width="300"> <br> Logo by <a href="https://github.com/hawkgs">Georgi Serev</a> </p>

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 to golint.

<p align="center"> <img src="./assets/demo.svg" alt="" width="700"> </p> <!-- toc -->

• Installation
  • Homebrew
  • Install from Sources
  • Docker
  • Manual Binary Download
• Usage
  • Text Editors
  • GitHub Actions
  • Continuous Integration
  • Linter aggregators
    • golangci-lint
  • Command Line Flags
  • Sample Invocations
  • Comment Directives
  • Configuration
  • Custom Configuration
  • Recommended Configuration
  • Rule-level file excludes
• Available Rules
• Configurable rules
  • var-naming
• Available Formatters
  • Friendly
  • Stylish
  • Default
  • Plain
  • Unix
  • JSON
  • NDJSON
  • Checkstyle
  • SARIF
• Extensibility
  • Writing a Custom Rule
    • Using revive as a library
  • Custom Formatter
• Speed Comparison
  • golint
  • revive's speed
• Overriding colorization detection
• Who uses Revive
• Contributors
  • Maintainers
  • All
• Star History
• License

<!-- tocstop -->

Installation

revive is available inside the majority of package managers.

<img alt="Repology packaging status" src="https://repology.org/badge/vertical-allrepos/revive.svg">

Homebrew

Install revive using brew:

brew install revive

To upgrade to the latest version:

brew upgrade revive

Install from Sources

Install the latest stable release directly from source:

go install github.com/mgechev/revive@latest

To install the latest commit from the main branch:

go install github.com/mgechev/revive@HEAD

Docker

You can run revive using Docker to avoid installing it directly on your system:

docker run -v "$(pwd)":/var/YOUR_REPOSITORY ghcr.io/mgechev/revive:v1.10.0 -config /var/YOUR_REPOSITORY/revive.toml -formatter stylish ./var/YOUR_REPOSITORY/...

Note: Replace YOUR_REPOSITORY with the path to your repository.

A volume must be mounted to share the current repository with the container. For more details, refer to the bind mounts Docker documentation.

• -v: Mounts the current directory ($(pwd)) to /var/YOUR_REPOSITORY inside the container.
• ghcr.io/mgechev/revive:v1.10.0: Specifies the Docker image and its version.
• revive: The command to run inside the container.
• Flags like -config and -formatter are the same as when using the binary directly.

Manual Binary Download

Download the precompiled binary from the Releases page:

1. Select the appropriate binary for your OS and architecture.
2. Extract the binary and move it to a directory in your PATH (e.g., /usr/local/bin).
3. Verify installation:

revive -version

Usage

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.

Text Editors

• Support for VSCode via vscode-go by changing the go.lintTool setting to revive:

{
  "go.lintTool": "revive",
}

• Support for GoLand via File Watchers.

• Support for vim via dense-analysis/ale.

  let g:ale_linters = {
  \   'go': ['revive'],
  \}
  

GitHub Actions

• Revive Action with annotation support

Continuous Integration

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)

Linter aggregators

golangci-lint

To enable revive in golangci-lint you need to add revive to the list of enabled linters:

# golangci-lint configuration file
version: "2"
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:
      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 passes 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 or JSON. See the golangci-lint website for more information about configuring revive.

Please notice that if no particular configuration is provided, revive will behave as golint does, i.e. all golint rules are enabled (the Available Rules table details what are the golint rules). When a configuration is provided, only rules in the configuration are enabled.

Command Line Flags

revive accepts the following command line parameters:

• -config [PATH] - path to the 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. If no exclusion patterns are specified, vendor/... will be excluded by default.

• -formatter [NAME] - formatter to be used for the output. The currently available formatters are:

  • default - will output the failures the same way that golint does.
  • json - outputs the failures in JSON format.
  • ndjson - outputs the failures as a stream in newline delimited JSON (NDJSON) format.
  • friendly - outputs the failures when found. Shows the 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, overwrites errorCode and warningCode in config.

• -version - get revive version.

Sample Invocations

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 ignore file1.go and