Comparison with other linters

[jsedgwick]

To wit, golangci-lint. My org is leaning towards you but we're having trouble with the comparison process, and want input from the authors themselves.

Is there a comparison of your project vs golangci-lint somewhere?

• see #42
• Extensibility/customizability comparison
• Speed comparison
• Ease of integration with GH checks API comparison

Thank you! And anything that you point out that is positive in comparison should by all means go in your readme. For market share reasons.

[mgechev]

Compared to gometalinter and golangci-lint, revive implements its own set of rules, instead of delegating this responsibility to other tools (for example, both gometalinter & golangci-lint are internally running golint, gocheck, gocyclo, etc.).

• Extensibility/customizability comparison

revive provides a framework for static code analysis - i.e., a set of primitive APIs which you can use to extend the standard set of rules. The current rules (which includes everything that golint already has + more) is built on top of these APIs. Anyone willing to add a custom rule is welcome to do so.

So, the way you add a new rule to gometalinter (and respectively golangci-lint) is by implementing another tool, publishing it to GitHub and opening a PR to gometalinter to introduce your new check. Implementing a new rule from scratch might not be trivial if you don't have the right abstractions. Publishing a check for the lines length (for example), in a separate repository and as a separate tool seems a bit redundant.

In contrast, adding a new rule to revive involves building on top of the abstract Rule struct that revive provides. After that you can either open a PR upstream, if you think the rule makes sense for the general audience, or maintain your own fork.

Ultimately, with revive you'd be able to implement the individual rules as plugins, but the ecosystem is not there yet.

• Speed comparison

Let's suppose that revive was using golint internally (similarly to gometalinter and golangci-lint). This means that at most revive would have been able to perform as well as golint. As the readme shows, revive is up to 6x faster than golint.

• Ease of integration with GH checks API comparison

I haven't done any GH integrations with revive. From what I see, GH consumes the output from the tool. Integrating revive with GitHub should not be more effort than golint or gometalinter.

Let me know if you have other questions. Also take a look at the blog post I published about the tool.

[jsedgwick]

@mgechev first off, thank you for the the stellar, quick, and thorough response.

Can I ask why (for example) you would implement your own cyclomatic complexity tool instead of delegating to gocyclo? Same would go for other useful linters - how do you plan on avoid NIH syndrome?

[jsedgwick]

Some context: we have an ambitious internal linter along the lines of clang-tidy. A big sell for revive would be the ability to just call out to it with no integration besides the call and reception of results.

[jsedgwick]

Better linting is on short-term (<1 month) roadmap for us, hence the attempt to decide between one or the other now.

[mgechev]

If you're planning to invoke an external linter, a better approach for you would be to use gometalinter/golangci-lint.

revive & gometalinter/golangci-lint are not mutually exclusive. You can run revive through gometalinter, for example. revive provides the framework for development of custom rules. If you want to use it as a standalone linter you can but that's not a requirement.

Can I ask why (for example) you would implement your own cyclomatic complexity tool instead of delegating to gocyclo? Same would go for other useful linters - how do you plan on avoid NIH syndrome?

There's a rule for cyclomatic complexity for completeness. I'm using revive in a pripriatary project where I didn't want to introduce gometalinter together with gocyclo given that I already have the rule execution & reporting mechanism in revive.

Three of the benefits I see of the approach I took with revive:

• Provides robust primitives for development of custom rules. There are a lot of boilerplates when working on a tool for static analysis and you write less redundant code when you have appropriate abstractions.
• Control over the performance of the linter. It's not dependent on the performance of the slowest linter from the toolchain (in case of concurrent execution) - it's dependent on the slowest rule. At first this looks the same, however, there's information which could be shared between the individual rules.
• Support for auto fixes. Running many "black boxes" tools concurrently makes performing auto fixes tricky.

[jsedgwick]

Thank you again for the great response! cc @diegs, @rodaine, @twoism