A Go Code Review Checklist

Questions to ask

Is the code gofmt-formatted and clean under go vet and a linter? Are all errors handled, wrapped with %w and checked with errors.Is/As? Are pointer receivers used for mutating methods? Are slices cloned before mutation when shared? Is map iteration order not relied on? Do goroutines have a clear owner, a way to stop (context), and bounded concurrency? Is shared state synchronised and tested with -race? Do HTTP servers set timeouts and shut down gracefully? Are tests table-driven with good coverage of edge cases?

The checklist

Use it in code reviews.

[ ] gofmt + go vet + staticcheck/golangci-lint clean
[ ] every error handled; wrapped with %w; checked with errors.Is / As
[ ] pointer receivers for mutation; consistent receiver types
[ ] slices cloned when shared; no reliance on map order
[ ] goroutines owned, cancellable via context, concurrency bounded
[ ] shared state behind mutex / atomics / channels; tests run with -race
[ ] http.Server timeouts; graceful Shutdown on SIGTERM
[ ] table-driven tests incl. boundaries and error paths
[ ] small interfaces defined by consumers; explicit dependencies
[ ] go mod tidy; govulncheck clean

Read Effective Go and the Code Review Comments

The official guides capture the conventions reviewers will expect.

Quick check: Which item belongs on a Go review checklist?

• Tests run with the -race flag in CI
• Ignore errors with _ by default
• Rely on map iteration order
• Use value receivers for mutating methods