Use consistent method receiver names SCC-ST1016
As our codebase grows, eventually we'll need to refactor some of it. For example, consider moving pieces of code between levels abstractions or
Poorly chosen name for variable of type time.Duration SCC-ST1011
time.Duration values represent an amount of time, which is represented as a count of nanoseconds. An expression like 5 * time.Microsecond yields the value 5000. It is therefore not appropriate to suffix a variable of type time.Duration with any time unit, such as Msec or Milli.
Poorly chosen name for error variable SCC-ST1012
The error variable name should be chosen carefully to convey the meaning of the error. It is recommended to use names like errFoo, ErrSomethingBad, ErrKindFoo or BazError for error variables that are part of an API. Examples:
A switch's default case should be the first or last case SCC-ST1015
For better readability, always place default of switch as first or last case.
Non-idiomatic comment formatting GO-C4004
Comments should have a space between the // and the comment text
A function's error value should be its last return value SCC-ST1008
Per convention, a function's error value should be its last return value.
Incorrect or missing package comment SCC-ST1000
Package comments, like all comments to be presented by godoc, must appear adjacent to the package clause, with no blank line.
Poorly chosen identifier SCC-ST1003
Identifiers, such as variable and package names, follow certain rules.
Incorrectly formatted error string SCC-ST1005
Error strings follow a set of guidelines to ensure uniformity and good composability. Quoting Go Code Review Comments:
Avoid zero-width and control characters in string literals SCC-ST1018
Zero-width characters are not printed, and may have been put in by mistake. Control characters (C0 and C1 characters and delete) are non-printing characters too. They should be avoided in the string literals.
Hex literal with mixed case letters CRT-A0005
It is not recommended to use Hex literal with mixed casing.
Types of function parameters can be combined CRT-A0017
If parameters of the same type lie consecutively, mention their type once at the end of the last parameter.
deferred function literal can be simplified GO-C4005
It is recommended to remove the wrapping function literal if it has a single function call. This makes the code succinct.
Regular expression can be simplified GO-C4007
Simplified regular expressions make the intent clear while being easier to refactor.
Function returns too many results GO-C4008
It is recommended to use a struct when a function returns too many results.
Method declaration preceding the type definition GO-C4009
It is idiomatic for the type definition to be before the method declarations.
TODO comments written without any detail or assignee GO-C4010
TODO comments should be accompanied by details or assignees and not left empty so that
they can be addressed later, and when it is referenced in the future, it will help define
the scope of the work.
Simplify Before or After call of time.Time GO-C4011
Some calls of Before or After for time.Time can be simplified and it is recommended
as well because the code will look simple and idiomatic.
Redundant type in variable declaration GO-C5001
Go infers the types of the variables if the type is not written explicitly. It is recommended to remove the type in the declaration for succinctness.
Redundant error checking RVV-B0005
Some simple error checking patterns can be reduced to just a single return
statement returning a variable of type Error.