As our codebase grows, eventually we'll need to refactor some of it. For example, consider moving pieces of code between levels abstractions or
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
The error variable name should be chosen carefully to convey the meaning of the error. It is recommended to use names like
BazError for error variables that are part of an API. Examples:
For better readability, always place
default of switch as first or last case.
Comments should have a space between the
// and the comment text
Per convention, a function's error value should be its last return value.
Package comments, like all comments to be presented by godoc, must appear adjacent to the package clause, with no blank line.
Identifiers, such as variable and package names, follow certain rules.
Error strings follow a set of guidelines to ensure uniformity and good composability. Quoting Go Code Review Comments:
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.
It is not recommended to use Hex literal with mixed casing.
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.
Simplified regular expressions make the intent clear while being easier to refactor.
It is recommended to use a struct when a function returns too many results.
It is idiomatic for the type definition to be before the method declarations.
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.
Some calls of
time.Time can be simplified and it is recommended
as well because the code will look simple and idiomatic.
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.
Some simple error checking patterns can be reduced to just a single
statement returning a variable of type