go/revive
1
0
Fork 0
mirror of https://github.com/mgechev/revive.git synced 2024-11-24 08:32:22 +02:00
Code Issues Releases Activity
8aa0cd8bd4
revive/RULES_DESCRIPTIONS.md
SalvadorC 8aa0cd8bd4 unhandled-error (new rule) (#124) 
* unhandled-error (new rule)

* better failure msg

* encapsulates error type detection
2019-04-27 19:23:17 -07:00

15 KiB
Raw Blame History

Description of available rules

List of all available rules.

add-constant

Description: Suggests using constant for magic numbers and string literals.

Configuration:

  • maxLitCount : (string) maximum number of instances of a string literal that are tolerated before warn.
  • allowStr: (string) comma-separated list of allowed string literals
  • allowInts: (string) comma-separated list of allowed integers
  • allowFloats: (string) comma-separated list of allowed floats

Example:

[rule.add-constant]
  arguments = [{maxLitCount = "3",allowStrs ="\"\"",allowInts="0,1,2",allowFloats="0.0,0.,1.0,1.,2.0,2."}]

argument-limit

Description: Warns when a function receives more parameters than the maximum set by the rule's configuration. Enforcing a maximum number of parameters helps to keep the code readable and maintainable.

Configuration: (int) the maximum number of parameters allowed per function.

Example:

[rule.argument-limit]
  arguments =[4]

atomic

Description: Check for commonly mistaken usages of the sync/atomic package

Configuration: N/A

bare-return

Description: Warns on bare (a.k.a. naked) returns

Configuration: N/A

blank-imports

Description: Blank import should be only in a main or test package, or have a comment justifying it.

Configuration: N/A

bool-literal-in-expr

Description: Using Boolean literals (true, false) in logic expressions may make the code less readable. This rule suggests removing Boolean literals from logic expressions.

Configuration: N/A

call-to-gc

Description: Explicitly invoking the garbage collector is, except for specific uses in benchmarking, very dubious.

The garbage collector can be configured through environment variables as described here.

Configuration: N/A

confusing-naming

Description: Methods or fields of struct that have names different only by capitalization could be confusing.

Configuration: N/A

confusing-results

Description: Function or methods that return multiple, no named, values of the same type could induce error.

Configuration: N/A

constant-logical-expr

Description: The rule spots logical expressions that evaluate always to the same value.

Configuration: N/A

context-as-argument

Description: By convention, context.Context should be the first parameter of a function. This rule spots function declarations that do not follow the convention.

Configuration: N/A

context-keys-type

Description: Basic types should not be used as a key in context.WithValue.

Configuration: N/A

cyclomatic

Description: Cyclomatic complexity is a measure of code complexity. Enforcing a maximum complexity per function helps to keep code readable and maintainable.

Configuration: (int) the maximum function complexity

Example:

[rule.cyclomatic]
  arguments =[3]

deep-exit

Description: Packages exposing functions that can stop program execution by exiting are hard to reuse. This rule looks for program exits in functions other than main() or init().

Configuration: N/A

dot-imports

Description: Importing with . makes the programs much harder to understand because it is unclear whether names belong to the current package or to an imported package.

More information here

Configuration: N/A

duplicated-imports

Description: It is possible to unintentionally import the same package twice. This rule looks for packages that are imported two or more times.

Configuration: N/A

empty-block

Description: Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring.

Configuration: N/A

empty-lines

Description: Sometimes gofmt is not enough to enforce a common formatting of a code-base; this rule warns when there are heading or trailing newlines in code blocks.

Configuration: N/A

error-naming

Description: By convention, for the sake of readability, variables of type error must be named with the prefix err.

Configuration: N/A

error-return

Description: By convention, for the sake of readability, the errors should be last in the list of returned values by a function.

Configuration: N/A

error-strings

Description: By convention, for better readability, error messages should not be capitalized or end with punctuation or a newline.

More information here

Configuration: N/A

errorf

Description: It is possible to get a simpler program by replacing errors.New(fmt.Sprintf()) with fmt.Errorf(). This rule spots that kind of simplification opportunities.

Configuration: N/A

exported

Description: Exported function and methods should have comments. This warns on undocumented exported functions and methods.

More information here

Configuration: N/A

file-header

Description: This rule helps to enforce a common header for all source files in a project by spotting those files that do not have the specified header.

Configuration: (string) the header to look for in source files.

Example:

[rule.file-header]
  arguments =["This is the text that must appear at the top of source files."]

flag-parameter

Description: If a function controls the flow of another by passing it information on what to do, both functions are said to be control-coupled. Coupling among functions must be minimized for better maintainability of the code. This rule warns on boolean parameters that create a control coupling.

Configuration: N/A

function-result-limit

Description: Functions returning too many results can be hard to understand/use.

Configuration: (int) the maximum allowed return values

Example:

[rule.function-result-limit]
  arguments =[3]

get-return

Description: Typically, functions with names prefixed with Get are supposed to return a value.

Configuration: N/A

if-return

Description: Checking if an error is nil to just after return the error or nil is redundant.

Configuration: N/A

increment-decrement

Description: By convention, for better readability, incrementing an integer variable by 1 is recommended to be done using the ++ operator. This rule spots expressions like i += 1 and i -= 1 and proposes to change them into i++ and i--.

Configuration: N/A

indent-error-flow

Description: To improve the readability of code, it is recommended to reduce the indentation as much as possible. This rule highlights redundant else-blocks that can be eliminated from the code.

More information here

Configuration: N/A

imports-blacklist

Description: Warns when importing black-listed packages.

Configuration: black-list of package names

Example:

[imports-blacklist]
  arguments =["crypto/md5", "crypto/sha1"]

import-shadowing

Description: In GO it is possible to declare identifiers (packages, structs, interfaces, parameters, receivers, variables, constants...) that conflict with the name of an imported package. This rule spots identifiers that shadow an import.

Configuration: N/A

line-length-limit

Description: Warns in the presence of code lines longer than a configured maximum.

Configuration: (int) maximum line length in characters.

Example:

[rule.line-length-limit]
  arguments =[80]

max-public-structs

Description: Packages declaring too many public structs can be hard to understand/use, and could be a symptom of bad design.

This rule warns on files declaring more than a configured, maximum number of public structs.

Configuration: (int) the maximum allowed public structs

Example:

[rule.max-public-structs]
  arguments =[3]

modifies-parameter

Description: A function that modifies its parameters can be hard to understand. It can also be misleading if the arguments are passed by value by the caller. This rule warns when a function modifies one or more of its parameters.

Configuration: N/A

modifies-value-receiver

Description: A method that modifies its receiver value can have undesired behavior. The modification can be also the root of a bug because the actual value receiver could be a copy of that used at the calling site. This rule warns when a method modifies its receiver.

Configuration: N/A

package-comments

Description: Packages should have comments. This rule warns on undocumented packages and when packages comments are detached to the package keyword.

More information here

Configuration: N/A

range

Description: This rule suggests a shorter way of writing ranges that do not use the second value.

Configuration: N/A

range-val-in-closure

Description: Range variables in a loop are reused at each iteration; therefore a goroutine created in a loop will point to the range variable with from the upper scope. This way, the goroutine could use the variable with an undesired value. This rule warns when a range value (or index) is used inside a closure

Configuration: N/A

receiver-naming

Description: By convention, receiver names in a method should reflect their identity. For example, if the receiver is of type Parts, p is an adequate name for it. Contrary to other languages, it is not idiomatic to name receivers as this or self.

Configuration: N/A

redefines-builtin-id

Description: Constant names like false, true, nil, function names like append, make, and basic type names like bool, and byte are not reserved words of the language; therefore the can be redefined. Even if possible, redefining these built in names can lead to bugs very difficult to detect.

Configuration: N/A

struct-tag

Description: Struct tags are not checked at compile time. This rule, checks and warns if it finds errors in common struct tags types like: asn1, default, json, protobuf, xml, yaml.

Configuration: N/A

superfluous-else

Description: To improve the readability of code, it is recommended to reduce the indentation as much as possible. This rule highlights redundant else-blocks that can be eliminated from the code.

Configuration: N/A

time-naming

Description: Using unit-specific suffix like "Secs", "Mins", ... when naming variables of type time.Duration can be misleading, this rule highlights those cases.

Configuration: N/A

var-naming

Description: This rule warns when variable or package naming conventions are not followed.

Configuration: 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)

Example:

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

var-declaration

Description: This rule proposes simplifications of variable declarations.

Configuration: N/A

unexported-return

Description: This rule warns when an exported function or method returns a value of an un-exported type.

Configuration: N/A

unhandled-error

Description: This rule warns when errors returned by a function are not explicitly handled on the caller side.

Configuration: N/A

unnecessary-stmt

Description: This rule suggests to remove redundant statements like a break at the end of a case block, for improving the code's readability.

Configuration: N/A

unreachable-code

Description: This rule spots and proposes to remove unreachable code.

Configuration: N/A

unused-parameter

Description: This rule warns on unused parameters. Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.

Configuration: N/A

unused-receiver

Description: This rule warns on unused method receivers. Methods with unused receivers can be a symptom of an unfinished refactoring or a bug.

Configuration: N/A

waitgroup-by-value

Description: Function parameters that are passed by value, are in fact a copy of the original argument. Passing a copy of a sync.WaitGroup is usually not what the developer wants to do. This rule warns when a sync.WaitGroup expected as a by-value parameter in a function or method.

Configuration: N/A