16 KiB
Description of available rules
List of all available rules.
- Description of available rules
- add-constant
- argument-limit
- atomic
- bare-return
- blank-imports
- bool-literal-in-expr
- call-to-gc
- confusing-naming
- confusing-results
- cognitive-complexity
- constant-logical-expr
- context-as-argument
- context-keys-type
- cyclomatic
- deep-exit
- dot-imports
- duplicated-imports
- empty-block
- empty-lines
- error-naming
- error-return
- error-strings
- errorf
- exported
- file-header
- flag-parameter
- function-result-limit
- get-return
- if-return
- increment-decrement
- indent-error-flow
- imports-blacklist
- import-shadowing
- line-length-limit
- max-public-structs
- modifies-parameter
- modifies-value-receiver
- package-comments
- range
- range-val-in-closure
- receiver-naming
- redefines-builtin-id
- struct-tag
- superfluous-else
- time-naming
- var-naming
- var-declaration
- unexported-return
- unhandled-error
- unnecessary-stmt
- unreachable-code
- unused-parameter
- unused-receiver
- waitgroup-by-value
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 literalsallowInts: (string) comma-separated list of allowed integersallowFloats: (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
cognitive-complexity
Description: Cognitive complexity is a measure of how hard code is to understand. While cyclomatic complexity is good to measure "testeability" of the code, cognitive complexity aims to provide a more precise measure of the difficulty of understanding the code. Enforcing a maximum complexity per function helps to keep code readable and maintainable.
Configuration: (int) the maximum function complexity
Example:
[rule.cognitive-complexity]
arguments =[7]
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: function names to ignore
Example:
[unhandled-error]
arguments =["fmt.Printf", "myFunction"]
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