Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md & Typo #1010

Merged
merged 2 commits into from
Jul 11, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 28 additions & 28 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -125,20 +125,20 @@ Since the default behavior of `revive` is compatible with `golint`, without prov
`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.

### Docker
A volume needs to be mounted to share the current repository with the container.
A volume must be mounted to share the current repository with the container.
Please refer to the [bind mounts Docker documentation](https://docs.docker.com/storage/bind-mounts/)

```bash
docker run -v "$(pwd)":/var/<repository> ghcr.io/mgechev/revive:v1.1.2-next -config /var/<repository>/revive.toml -formatter stylish ./var/kidle/...
docker run -v "$(pwd)":/var/<repository> ghcr.io/mgechev/revive:v1.3.7 -config /var/<repository>/revive.toml -formatter stylish ./var/kidle/...
```

- `-v` is for the volume
- `ghcr.io/mgechev/revive:v1.1.2-next ` is the image name and its version corresponding to `revive` command
- `ghcr.io/mgechev/revive:v1.3.7 ` is the image name and its version corresponds to `revive` command
- The provided flags are the same as the binary usage.

### Bazel

If you want to use revive with Bazel, take a look at the [rules](https://github.com/atlassian/bazel-tools/tree/master/gorevive) that Atlassian maintains.
If you want to use revive with Bazel, look at the [rules](https://github.com/atlassian/bazel-tools/tree/master/gorevive) that Atlassian maintains.

### Text Editors

Expand Down Expand Up @@ -208,14 +208,14 @@ Please notice that if no particular configuration is provided, `revive` will beh

`revive` accepts the following command line parameters:

- `-config [PATH]` - path to config file in TOML format, defaults to `$HOME/revive.toml` if present.
- `-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.
- `-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 stream in newline delimited JSON (NDJSON) format.
- `friendly` - outputs the failures when found. Shows summary of all the failures.
- `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](https://checkstyle.org/).
- `-max_open_files` - maximum number of open files at the same time. Defaults to unlimited.
Expand All @@ -236,7 +236,7 @@ revive -config revive.toml -exclude file1.go -exclude file2.go -formatter friend

### Comment Directives

Using comments, you can disable the linter for the entire file or only range of lines:
Using comments, you can disable the linter for the entire file or only a range of lines:

```go
//revive:disable
Expand All @@ -259,7 +259,7 @@ func Public() 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.
This way, `revive` will not warn you 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

Expand All @@ -285,7 +285,7 @@ in the configuration. You can set the severity (defaults to _warning_) of the vi

### Configuration

`revive` can be configured with a TOML file. Here's a sample configuration with explanation for the individual properties:
`revive` can be configured with a TOML file. Here's a sample configuration with an explanation of the individual properties:

```toml
# When set to false, ignores files with "GENERATED" header, similar to golint
Expand All @@ -298,7 +298,7 @@ severity = "warning"
# with less than 0.8 confidence will be ignored.
confidence = 0.8

# Sets the error code for failures with severity "error"
# Sets the error code for failures with the "error" severity
errorCode = 0

# Sets the error code for failures with severity "warning"
Expand All @@ -323,7 +323,7 @@ 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.
This will enable all available rules no matter what rules are named in the configuration file.

To disable a rule, you simply mark it as disabled in the configuration.
For example:
Expand All @@ -333,7 +333,7 @@ For example:
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:
The following file is an example configuration where all rules are enabled, except for those that are explicitly disabled, and some rules are configured with particular arguments:

```toml
severity = "warning"
Expand Down Expand Up @@ -429,7 +429,7 @@ warningCode = 0

You also can setup custom excludes for each rule.

It's alternative for global `-exclude` program arg.
It's an alternative for the global `-exclude` program arg.

```toml
ignoreGeneratedHeader = false
Expand All @@ -444,17 +444,17 @@ warningCode = 0
Exclude=["src/somepkg/*.go", "TEST"]
```

You can use following exclude patterns
You can use the following exclude patterns

1. full paths to files `src/pkg/mypkg/some.go`
2. globs `src/**/*.pb.go`
3. regexes (should have prefix ~) `~\.(pb|auto|generated)\.go$`
4. well-known `TEST` (same as `**/*_test.go`)
5. special cases:
a. `*` and `~` patterns exclude all files (same effect than disabling the rule)
a. `*` and `~` patterns exclude all files (same effect as disabling the rule)
b. `""` (empty) pattern excludes nothing

> NOTE: do not mess with `exclude` that can be used at top level of TOML file, that mean "exclude package patterns", not "exclude file patterns"
> NOTE: do not mess with `exclude` that can be used at the top level of TOML file, that means "exclude package patterns", not "exclude file patterns"

## Available Rules

Expand Down Expand Up @@ -539,7 +539,7 @@ List of all available rules. The rules ported from `golint` are left unchanged a
| [`enforce-slice-style`](./RULES_DESCRIPTIONS.md#enforce-slice-style) | string (defaults to "any") | Enforces consistent usage of `make([]type, 0)` or `[]type{}` for slice initialization. Does not affect `make(map[type]type, non_zero_len, or_non_zero_cap)` constructions. | no | no |
| [`enforce-repeated-arg-type-style`](./RULES_DESCRIPTIONS.md#enforce-repeated-arg-type-style) | string (defaults to "any") | Enforces consistent style for repeated argument and/or return value types. | no | no |
| [`max-control-nesting`](./RULES_DESCRIPTIONS.md#max-control-nesting) | int (defaults to 5) | Sets restriction for maximum nesting of control structures. | no | no |
| [`comments-density`](./RULES_DESCRIPTIONS.md#comments-density) | int (defaults to 0) | Enforces a minumum comment / code relation | no | no |
| [`comments-density`](./RULES_DESCRIPTIONS.md#comments-density) | int (defaults to 0) | Enforces a minimum comment / code relation | no | no |


## Configurable rules
Expand All @@ -555,7 +555,7 @@ This rule accepts two slices of strings, an allowlist and a blocklist of initial
arguments = [["ID"], ["VM"]]
```

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

## Available Formatters

Expand All @@ -577,7 +577,7 @@ The default formatter produces the same output as `golint`.

### Plain

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

![Plain formatter](/assets/formatter-plain.png)

Expand Down Expand Up @@ -616,7 +616,7 @@ The `Arguments` type is an alias of the type `[]interface{}`. The arguments of t

#### Example

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:
Let's suppose we have developed a rule called `BanStructNameRule` which disallow us to name a structure with a given identifier. We can set the banned identifier by using the TOML configuration file:

```toml
[rule.ban-struct-name]
Expand All @@ -625,16 +625,16 @@ Let's suppose we have developed a rule called `BanStructNameRule` which disallow

With the snippet above we:

- Enable the rule with name `ban-struct-name`. The `Name()` method of our rule should return a string which matches `ban-struct-name`.
- Enable the rule with the name `ban-struct-name`. The `Name()` method of our rule should return a string that matches `ban-struct-name`.
- Configure the rule with the argument `Foo`. The list of arguments will be passed to `Apply(*File, Arguments)` together with the target file we're linting currently.

A sample rule implementation can be found [here](/rule/argument-limit.go).

#### 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 own linter using `revive` as linting engine.
(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 own application.
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.
Expand All @@ -661,7 +661,7 @@ func (f myRule) Name() string {
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:
You can still go further and use `revive` without its CLI, as part of your library, or your CLI:

```go
package mylib
Expand Down Expand Up @@ -728,7 +728,7 @@ For a sample formatter, take a look at [this file](/formatter/json.go).

## 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:
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

Expand All @@ -751,7 +751,7 @@ 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`:
Keep in mind that if you use rules that require type checking, the performance may drop to 2x faster than `golint`:

```shell
# type checking enabled
Expand All @@ -762,7 +762,7 @@ 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.
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

Expand Down
10 changes: 5 additions & 5 deletions rule/comments-density.go
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ import (

// CommentsDensityRule lints given else constructs.
type CommentsDensityRule struct {
minumumCommentsDensity int64
minimumCommentsDensity int64
configured bool
sync.Mutex
}
Expand All @@ -29,12 +29,12 @@ func (r *CommentsDensityRule) configure(arguments lint.Arguments) {
r.configured = true

if len(arguments) < 1 {
r.minumumCommentsDensity = defaultMinimumCommentsPercentage
r.minimumCommentsDensity = defaultMinimumCommentsPercentage
return
}

var ok bool
r.minumumCommentsDensity, ok = arguments[0].(int64)
r.minimumCommentsDensity, ok = arguments[0].(int64)
if !ok {
panic(fmt.Sprintf("invalid argument for %q rule: argument should be an int, got %T", r.Name(), arguments[0]))
}
Expand All @@ -48,12 +48,12 @@ func (r *CommentsDensityRule) Apply(file *lint.File, arguments lint.Arguments) [
statementsCount := countStatements(file.AST)
density := (float32(commentsLines) / float32(statementsCount+commentsLines)) * 100

if density < float32(r.minumumCommentsDensity) {
if density < float32(r.minimumCommentsDensity) {
return []lint.Failure{
{
Node: file.AST,
Confidence: 1,
Failure: fmt.Sprintf("the file has a comment density of %2.f%% (%d comment lines for %d code lines) but expected a minimum of %d%%", density, commentsLines, statementsCount, r.minumumCommentsDensity),
Failure: fmt.Sprintf("the file has a comment density of %2.f%% (%d comment lines for %d code lines) but expected a minimum of %d%%", density, commentsLines, statementsCount, r.minimumCommentsDensity),
},
}
}
Expand Down
Loading