Code Inspections in Go
This topic lists all GoLand code inspections available in Go.
You can toggle specific inspections or change their severity level on the Editor | Inspections page of the IDE settings CtrlAlt0S.
Inspection | Description | Default Severity |
---|---|---|
'FailNow' in a non-test goroutine | Reports calls to Methods like For more information about Example:
After the Replace with 'Error' and 'return' quick-fix is applied:
| |
'Unmarshal' is called with the incorrect argument | Reports calls to These calls will fail and return an error. For more information about Example:
After the Prepend '&' quick-fix is applied:
| |
'context.CancelFunc' is not called | Reports execution paths that do not call the The For more information about the Example:
| |
Defer/go statement calls 'recover' or 'panic' directly | Reports Such statements are rarely useful and might indicate a misuse of the
For more information about go statements and panics handling, see Handling panics and Go statements in the Go Language Specification. | |
Division by zero | Reports division by zero. Division by zero will lead to a runtime panic. Example:
| |
Exceeded shift expression | Reports shift expressions that equal or exceed the width of the integer. All the bits of the left operand are shifted in such expression resulting in a constant value. The constant value indicates that either the shift offset is incorrect or the shift expression is redundant. Example:
| |
Imported package name as a name identifier | Reports declarations of variables, arguments or functions that overlap with the used import. While legal, such declarations will make using the package exported identifiers impossible after the declaration or create confusion when reading the code. Example:
Variable names | |
Impossible interface type assertion | Reports impossible interface-to-interface type assertions. Checks for type assertions Example:
The This inspection only reports if the language version is 1.15 or higher. | |
Incorrect 'strings.Replace' count argument | Reports The count argument for how many times a string should be replaced should not be Example:
| |
Incorrect usage of 'fmt.Printf' and 'fmt.Println' functions | Reports incorrect usages of In their format strings, formatting functions use formatting verbs, like Example:
The output of this function is
| |
Incorrect usage of the 'errors.As' function | Reports calls of the Such calls panic at runtime. For more information about the Example:
After the Prepend '&' quick-fix is applied:
This inspection only reports if the language version is 1.13 or higher. | |
Incorrect usage of the 'sync/atomic' package | Reports assignment statements of the form Such operations are not atomic, and is a common misuse of the Example:
| |
Integer to string type conversion | Reports conversions of Such conversions are discouraged because they return the UTF-8 representation of the Unicode code point For conversions that intend on using the code point, consider replacing them with Example:
After the Convert integer to rune quick-fix is applied:
| |
Invalid conversions of 'uintptr' to 'unsafe.Pointer' | Reports possibly incorrect conversions of A conversion from Example of invalid usage:
Example of valid usage:
| |
Irregular usage of 'iota' | Reports irregular usage of The For details, see Iota in the Go specification. This inspection is triggered if two constant specifications have a textually identical expression list containing at least one reference to Consider omitting the redundant expression list or writing out the expression list every time. Example:
Triggers the inspection as the Example:
Does not trigger the inspection as none of the expression lists is redundant. | |
Leading whitespace in directive comment | Reports leading whitespaces before Go directives in comments. Go directives are not recognized if there is whitespace between The quick-fix removes the leading whitespace before the Go directive. Example:
After the quick fix is applied:
| |
Locks mistakenly passed by value | Reports locks that are mistakenly passed by values. Accidentally copying a value containing a lock may cause both copies to work incorrectly. Generally, such values should be referred to through a pointer. A lock here means a type implementing Example:
After the Add pointer quick-fix is applied:
| |
Loop variables captured by the func literal | Reports references to loop variables from within For more information about closures and goroutines, see What happens with closures running as goroutines? at go.dev. Example:
After the quick-fix is applied:
Note the analyzer only checks | |
Malformed build tag | Reports malformed build tags and build tags in the incorrect location. The See Build Constraints at go.dev. Example:
The
| |
Malformed struct tag | Reports struct tags that do not conform to Go conventions for struct tags. According to these conventions, tag strings are a concatenation of optionally space-separated Also, the inspection checks that fields with tags are exported. Example of a valid tag:
| |
Mixed value and pointer receivers | Reports structures with methods that use a mixture of types: value and pointer receivers. Such usage is not recommended by the Go Documentation. For details, see Should I define methods on values or pointers? in the Go FAQ. Example:
| |
Nilness analyzer | Reports problems caused by incorrect usage of the The IDE analyses data flow to determine if variables could have
| |
Non-standard signature for well-known function names | Reports methods with certain names in the following cases:
Such methods might indicate that the receiver type is intended to satisfy an interface from the standard library, but fails to do so because of the mistake in the method's signature. Example:
The usage is suspicious because it looks like an attempt to implement
| |
Reserved word used as name | Reports declarations of variables, arguments or functions that overlap with the built-in or reserved keyword. If you receive this error then your code might not be as explicit as possible and might confuse other users. Example:
Types | |
Shadowing variable | Reports declarations of variables that overlap with the declarations in the outer scope. As the meaning of the variable depends on the scope in that case, it may create confusion and lead to unintended consequences. Example:
The
| |
Unhandled error | Reports calls to functions and methods that do not handle the call result of the An API of such functions imply that their execution might finish unsuccessfully and they would return an error. Calls that do not handle the error result could be an indication of the API misuse. Example:
After the Handle error quick-fix is applied:
| |
Unused function or method call result | Reports calls to certain functions and methods that do not handle a call result. An API of such functions imply that users should call them mostly to get a return value and process it, not for side effects. Calls that do not handle the result could be an indication of a misuse of the API. Example:
After the Introduce local variable quick-fix is applied:
| |
Inspection | Description | Default Severity |
---|---|---|
'defer' in the loop | Reports Using Example:
Calls of | |
Assignment to a receiver | Reports assignments to method receivers. When you assign a value to the method receiver, the value will not be reflected outside of the method itself. Values will be reflected in subsequent calls from the same method. Example:
| |
Infinite 'for' loop | Reports empty Running this code will make the CPU usage stay at maximum and will make the machine nearly unusable. Example:
| |
Unreachable code | Reports code that can never be executed because there exists no control flow path to the code from the rest of the program. Example:
| |
Inspection | Description | Default Severity |
---|---|---|
Comment has no leading space | Reports comments without a leading space. Note that the inspection works only if you select the Add a leading space to comments in Editor | Code Style | Go on the Other tab. Comments with a leading space can be easier to read since the first word is separated from the comment by a space. Example:
| |
Comment of exported element starts with the incorrect name | Reports comments that do not start with the name of the exported element. According to Comment Sentences at github.com/golang, this is a convention to begin a comment with the name of the exported element. Example:
The comment starts with the struct description, not with the struct name. To stick to the convention rules, you can apply the Add prefix to comment quick-fix. After the quick-fix is applied, the comment looks as follows:
| |
Convert string literals | Reports double-quoted string literals that can be converted into raw string literals and raw string literals that can be converted to double-quoted string literals. Example:
After the quick fix is applied:
There are two notes that you should take into account while converting double-quoted strings to raw strings:
| |
Error string should not be capitalized or end with punctuation | Reports format issues in error strings. Example:
According to Error Strings at github.com/golang, error strings should not be capitalized or end with punctuation because they might appear among other context. To fix the format, you can apply the Fix error string format quick-fix. After the quick-fix is applied, the error string will look like this:
| |
Exported element should have a comment | Reports exported declarations without a documentation comment. According to Doc Comments at github.com/golang, all top-level exported names should have doc comments. Also, for more information about comment sentences, see Comment Sentences at github.com/golang. To add a comment, you can apply the Add comment quick-fix. | |
Exported element should have its own declaration | Reports exported variables or constants in comma-separated lists of declarations. Example:
This declaration makes it hard to understand what value each constant has. You can apply the Extract to own declaration quick-fix to make this declaration more readable. After the quick-fix is applied to each constant, the declaration looks as follows:
| |
Name starts with a package name | Reports exported names that start with a package name. This inspection does not report such names in the Example:
The According to Package Names at github.com/golang, all references to names in a package will be done using the package name, so one can omit that name from the identifiers. For example, if you are in a package | |
Receiver has a generic name | Reports receiver names like Example:
According to Receiver Names at github.com/golang, you should not use generic names such as "me", "this", or "self". These identifiers are typical for object-oriented languages and might give the method a special meaning. | |
Struct initialization without field names | Reports structures that are initialized without specifying their field names. By default, the inspection is available only when you use the type that is defined in a different package. When initializing a structure, it is better to explicitly state field names in order to ensure that in case of changes in order of these fields or in names of the fields, they will correctly continue to be addressed. Example:
The
The inspection has the following options:
| |
Type parameter is declared in lowercase | Reports type parameters that are declared in lowercase. Examples in the official Go documentation use type parameters in uppercase. This inspection follows this uppercase rule for type parameters.
The type parameter | |
Unit-specific suffix for 'time.Duration' | Reports unit-specific suffixes in constant and variable names of The inspection comes from
Example:
| |
Unsorted imports | Reports unsorted imports. All Go programs should be formatted in the same way, the formatting rules are fixed by the gofmt tool. Those rules require imports to be sorted. Example of a wrong sorting:
You can apply the Sort imports quick-fix to fix the sorting. After the quick-fix is applied, the sorting looks as follows:
| |
Usage of Snake_Case | Reports usage of snake case instead of camelcase for naming variables, constants and functions. According to MixedCaps at go.dev, camelcase is a convention in Go. Example:
The | |
Inspection | Description | Default Severity |
---|---|---|
Deprecated element | Reports usages of deprecated elements. Example:
According to Constants at go.dev, | |
Disabled GOPATH indexing | Reports disabled GOPATH indexing that might prevent proper resolution of code references. GOPATH stores your code base and all the files that are necessary for your development. Also, it includes packages that you download and install. If you disabled GOPATH indexing, only project and vendored packages are indexed. It might improve the overall performance but makes it impossible to use packages from GOPATH. | |
Fuzzing is supported starting with Go 1.18 | Reports presence of fuzz tests when Go SDK version is less than 1.18 Fuzz testing is a method of automated testing that involves a directed search for input data that may cause a program crash or expose invalid behavior. Go supports fuzz testing starting from Go 1.18. Example of a fuzz test:
See Go Fuzzing for more information. | |
Malformed test function name | Reports malformed names of tests, benchmarks, and examples. According to Package testing at go.dev, names must follow a special convention in order to make the go tool process them correctly. Example:
After the Rename to quick-fix is applied:
| |
Missing trailing comma before a newline in a composite literal | Reports a missing trailing comma before a newline in composite literals, function call arguments, and function parameter lists. Example:
| |
Redundant parentheses | Reports redundant parentheses in expressions and types. Example:
After the Unwrap parentheses quick-fix is applied:
| |
Unexported return type of the exported function | Reports exported functions with unexported return types. Unexported types can be difficult to use when viewing documentation under go doc. Example:
You can apply Export quick-fix to export the type. After the quick-fix is applied, type name will be capitalized:
| |
Unnecessarily exported identifier | Reports exported identifiers that are used only in the package where they are defined but are not used in other packages. Making them exported is redundant and may clutter the API of the package. | |
Usage of 'interface{}' as a type | Reports usages of the empty interface as a type or type constraint. The empty interface denotes the set of all types. Go 1.18 introduced the more explicit alias The inspection is triggered for any usage of an empty interface as a type or type constraint. Aliases of the empty interface and interfaces that exclusively embed other empty interfaces do not trigger the inspection. Consider using the more explicit alias | |
Usage of context.TODO() | Reports usages of According to the documentation at pkg.go.dev, you need to use Note that it is a temporary placeholder, and you must change it in the future to a more meaningful context (for example, |
Inspection | Description | Default Severity |
---|---|---|
Vulnerable API usage | Reports usages of Vulnerable APIs of imported dependencies. Fixing the reported problems helps prevent your software from being compromised by an attacker. To solve a problem, you can update to a version where the vulnerability is fixed (if available) or switch to a dependency that doesn't have the vulnerability. Vulnerability data provided by Checkmarx (c). | |
Inspection | Description | Default Severity |
---|---|---|
Bool condition | Reports parts of boolean expressions that are either always Example:
You can apply the Simplify expression quick-fix for the | |
Empty declaration | Reports empty declarations. Empty declarations have no effect. If you remove them, you might improve code readability. Example:
You can apply the Delete empty declaration quick-fix to remove this declaration. | |
Empty slice declared using a literal | Reports slice declarations with empty literal initializers used instead of An empty slice can be represented by Example:
To change the declaration, use the Replace with nil slice declaration (changes semantics) quick-fix. After the quick-fix is applied:
| |
Redundant blank argument in range | Reports optional blank variables in range loops. When you use the Example:
To remove the blank identifier, you can use the Delete blank argument quick-fix. After the quick-fix is applied, the code will look as follows:
| |
Redundant comma | Reports commas that may be omitted in the end of argument lists and composite literals. The IDE suggests removing commas that are considered optional. Removing these commas might improve code readability. Example:
| |
Redundant import alias | Reports aliases of imported packages that may be omitted. Usually, such aliases equal to the names of the imported packages, so aliases have no effect and one can use package names directly. Example:
The After the quick-fix is applied:
| |
Redundant second index in slices | Reports a redundant second index (a high bound) in slice expressions. Usually, the second index is optional. If you remove it, you might improve code readability. Example:
You can apply the Remove redundant index quick-fix to such cases. After the quick-fix is applied, this code looks as follows:
| |
Redundant semicolon | Reports redundant semicolons. Idiomatic Go programs have semicolons only in places such as For more information about semicolons in Go, see Semicolons at go.dev. Example:
| |
Redundant type conversion | Reports type conversions that may be omitted. Example:
The After the quick-fix is applied:
Sometimes conversion of a floating expression to a floating type can be intentional (see this issue as an example). In such cases, the IDE issues a warning about a possibly redundant conversion. | |
Redundant types in composite literals | Reports redundant type declarations in composite literals. Example:
We have a slice of slices of the
For more information about composite literals, see Go Language Specification: Composite Literals at go.dev. | |
Self assignment | Reports expressions that are assigned to themselves. Such assignments have no effect, removing them might improve code readability. Example:
| |
Type can be omitted | Reports types in variable and constant declarations that can be omitted since they can be inferred by the compiler. Such types are redundant, omitting them may improve readability of the code. Example:
The
| |
Unused constant | Reports constants that are defined but are never used in code.
Unlike unused variables and imports, this code will compile. Unused constants might increase your code base and slow down program compilation. To delete the unused constant, consider using the Delete constant quick-fix. | |
Unused exported function | Reports unused exported functions. In Go, a function is exported if it begins with a capital letter. Names of exported functions that were defined but never used are grayed out.
| |
Unused exported type | Reports unused exported types in the
The | |
Unused function | Reports unused unexported functions. In Go, a function is unexported if it begins with a small letter. Names of unexported functions that were defined but never used are grayed out.
| |
Unused global variable | Reports global variables that are defined but are never used in code. If you have unused variables, the code will not compile. For more information about unused variables and imports, see Unused imports and variables at go.dev.
Code in the example will not compile. Therefore, it is highlighted as an error. You can apply two quick-fixes for such cases: Delete variable and Rename to _. The first quick-fix deletes the variable, the second one will convert the variable to a blank identifier. After the Rename to _ quick-fix is applied:
| |
Unused parameter | Reports unused function parameters.
We call the printAll function passing | |
Unused type | Reports unused types.
The | |
Unused type parameter | Reports unused type parameters.
The printAll function has two type parameters | |
Thanks for your feedback!