Linters

Canonical guidance

• run go vet by default
• add extra linters only if the team will keep them actionable
• treat repeated lint findings as process or design problems

Use when

• CI pipelines
• pre-merge checks
• large codebases with many contributors

Avoid

• disabling findings without understanding them
• running a huge linter bundle nobody respects
• treating lint as style-only busywork

Preferred pattern

go vet ./...
go test ./...

Anti-pattern

• relying on code review alone to catch shadowing, suspicious formatting directives, or obvious misuse patterns

Explanation: This anti-pattern is tempting because review feels sufficient, but machines are better at repetitive detection and humans are better at design judgment.

Why

• static analysis finds low-level mistakes early and consistently