revive.toml
# When set to false, ignores files with "GENERATED" header, similar to golint
ignoreGeneratedHeader = false
# Sets the default severity to "warning"
severity = "error"
# Sets the default failure confidence. This means that linting errors
# with less than 0.8 confidence will be ignored.
confidence = 0.8
# Sets the error code for failures with severity "error"
errorCode = 1
# Sets the error code for failures with severity "warning"
warningCode = 1
# Check for commonly mistaken usages of the sync/atomic package
[rule.atomic]
# Warns on bare (a.k.a. naked) returns
[rule.bare-return]
# Blank import should be only in a main or test package, or have a comment justifying it.
[rule.blank-imports]
# Using Boolean literals (true, false) in logic expressions may make the code less
# readable. This rule suggests removing Boolean literals from logic expressions.
[rule.bool-literal-in-expr]
# Explicitly invoking the garbage collector is, except for specific uses in
# benchmarking, very dubious.
[rule.call-to-gc]
# 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.
[rule.cognitive-complexity]
arguments =[10]
# Methods or fields of struct that have names different only by capitalization could be
# confusing.
[rule.confusing-naming]
# unction or methods that return multiple, no named, values of the same type could
# induce error.
[rule.confusing-results]
# The rule spots logical expressions that evaluate always to the same value.
[rule.constant-logical-expr]
# By convention, context.Context should be the first parameter of a function. This rule
# spots function declarations that do not follow the convention.
[rule.context-as-argument]
# Configuration of the `cyclomatic` rule. Here we specify that
# the rule should fail if it detects code with higher complexity than 10.
[rule.cyclomatic]
arguments = [10]
# 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().
[rule.deep-exit]
# mporting with . makes the programs much harder to understand because it is unclear
# whether names belong to the current package or to an imported package.
[rule.dot-imports]
# It is possible to unintentionally import the same package twice. This rule looks for
# packages that are imported two or more times.
[rule.duplicated-imports]
# Empty blocks make code less readable and could be a symptom of a bug or unfinished
# refactoring.
[rule.empty-block]
# By convention, for the sake of readability, variables of type error must be named with
# the prefix err.
[rule.error-naming]
# By convention, for better readability, error messages should not be capitalized or end
# with punctuation or a newline.
[rule.error-strings]
# Exported function and methods should have comments. This warns on undocumented
# exported functions and methods.
# [rule.exported]
# 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.
[rule.errorf]
# Functions returning too many results can be hard to understand/use.
[rule.function-result-limit]
arguments =[3]
# Typically, functions with names prefixed with Get are supposed to return a value.
[rule.get-return]
# Checking if an error is nil to just after return the error or nil is redundant.
[rule.if-return]
# 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--.
[rule.increment-decrement]
# 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.
[rule.indent-error-flow]
# 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.
[rule.import-shadowing]
# Warns in the presence of code lines longer than a configured maximum.
[rule.line-length-limit]
arguments = [120]
# 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.
[rule.modifies-value-receiver]
# This rule suggests a shorter way of writing ranges that do not use the second value.
[rule.range]
# 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
[rule.range-val-in-closure]
# 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.
[rule.receiver-naming]
# 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.
[rule.redefines-builtin-id]
# 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.
[rule.struct-tag]
# 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.
[rule.superfluous-else]
# This rule warns when variable or package naming conventions are not followed.
[rule.var-naming]
arguments = [["HTTP", "ID", "JSON", "API"],[]]
# This rule proposes simplifications of variable declarations.
[rule.var-declaration]
# This rule warns when errors returned by a function are not explicitly handled on the
# caller side.
[rule.unhandled-error]
# This rule suggests to remove redundant statements like a break at the end of a case
# block, for improving the code's readability.
[rule.unnecessary-stmt]
# 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.
[rule.waitgroup-by-value]