go-code-review

Go Code Review

Structured code review process for Go. Reviews should be constructive, specific, and cite the relevant principle behind each finding.

Operating Modes

Pick the mode that matches the request before starting:

• Diff review (default) — review only the changed lines plus enough surrounding context to judge them. Use for PRs and working-tree changes.
• File/package review — review the named files or packages in full, including their tests.
• Full audit — sweep the entire codebase. Use the strategy in "Auditing Large Codebases" below and aggregate everything into one report.

Review Process

Execute these steps in order. For each finding, classify severity:

• 🔴 BLOCKER — Must fix before merge. Correctness, data loss, security.
• 🟡 WARNING — Should fix. Maintainability, idiomatic Go, clarity.
• 🟢 SUGGESTION — Consider improving. Style, naming, documentation.

0. Run the Toolchain First

Before reading code manually, let the tools catch the mechanical issues (skip any tool that is not installed and note it in the report):

go build ./...          # it must compile
go vet ./...            # suspicious constructs
golangci-lint run       # if the repo has a config
go test -race ./...     # tests pass, no data races

Report tool findings alongside manual findings — a failing go vet is an automatic 🔴 BLOCKER. Never report an issue a tool already proves absent.

1. Correctness & Safety

Error Handling

• Every error is checked. No blank identifier _ discarding errors silently.
• Errors are wrapped with context: fmt.Errorf("fetch user %d: %w", id, err).
• Error values compared with errors.Is() / errors.As(), never ==.
• No panic outside of init() or truly unrecoverable situations.
• Errors handled exactly once — no log-and-return patterns.

Nil Safety

• Pointer receivers checked before dereference when nil is a valid state.
• Map reads guarded or use comma-ok idiom.
• Channel operations consider closed/nil channels.
• Slice operations check bounds where relevant.