Go Code Review Checklist

Based on Go Wiki CodeReviewComments. This checklist provides quick review points with references to detailed skills.

Formatting

• • gofmt: Code is formatted with gofmt or goimports → go-linting

Documentation

• • Comment sentences: Comments are full sentences starting with the name being described, ending with a period → go-documentation
• • Doc comments: All exported names have doc comments; non-trivial unexported declarations too → go-documentation
• • Package comments: Package comment appears adjacent to package clause with no blank line → go-documentation
• • Named result parameters: Only used when they clarify meaning (e.g., multiple same-type returns), not just to enable naked returns → go-documentation

Error Handling

• • Handle errors: No discarded errors with _; handle, return, or (exceptionally) panic → go-error-handling
• • Error strings: Lowercase, no punctuation (unless starting with proper noun/acronym) → go-error-handling
• • In-band errors: No magic values (-1, "", nil); use multiple returns with error or ok bool → go-error-handling
• • Indent error flow: Handle errors first and return; keep normal path at minimal indentation → go-error-handling

Naming

• • MixedCaps: Use MixedCaps or mixedCaps, never underscores; unexported is maxLength not MAX_LENGTH → go-naming
• • Initialisms: Keep consistent case: URL/url, ID/id, HTTP/http (e.g., ServeHTTP, xmlHTTPRequest) → go-naming
• • Variable names: Short names for limited scope (i, r, c); longer names for wider scope → go-naming
• • Receiver names: One or two letter abbreviation of type (c for Client); no this, self, me; consistent across methods → go-naming
• • Package names: No stuttering (use chubby.File not chubby.ChubbyFile); avoid util, common, misc → go-packages

Concurrency

• • Goroutine lifetimes: Clear when/whether goroutines exit; document if not obvious → go-concurrency
• • Synchronous functions: Prefer sync over async; let callers add concurrency if needed → go-concurrency
• • Contexts: First parameter; not in structs; no custom Context types; pass even if you think you don't need to → go-context

Interfaces

• • Interface location: Define in consumer package, not implementor; return concrete types from producers → go-interfaces
• • No premature interfaces: Don't define before used; don't define "for mocking" on implementor side → go-interfaces
• • Receiver type: Use pointer if mutating, has sync fields, or is large; value for small immutable types; don't mix → go-interfaces

Data Structures

• • Empty slices: Prefer var t []string (nil) over t := []string{} (non-nil zero-length) → go-data-structures
• • Copying: Be careful copying structs with pointer/slice fields; don't copy *T methods' receivers by value → go-data-structures

Security

• • Crypto rand: Use crypto/rand for keys, not math/rand → go-defensive
• • Don't panic: Use error returns for normal error handling; panic only for truly exceptional cases → go-defensive

Style

• • Line length: No rigid limit, but avoid uncomfortably long lines; break by semantics, not arbitrary length → go-style-core
• • Naked returns: Only in short functions; explicit returns in medium/large functions → go-style-core
• • Pass values: Don't use pointers just to save bytes; pass string not *string for small fixed-size types → go-performance

Imports

• • Import groups: Standard library first, then blank line, then external packages → go-packages
• • Import renaming: Avoid unless collision; rename local/project-specific import on collision → go-packages
• • Import blank: import _ "pkg" only in main package or tests → go-packages
• • Import dot: Only for circular dependency workarounds in tests → go-packages

Testing

• • Examples: Include runnable Example functions or tests demonstrating usage → go-documentation
• • Useful test failures: Messages include what was wrong, inputs, got, and want; order is got != want → go-testing

Quick Review Commands

# Format and organize imports
goimports -w .

# Run linter suite
golangci-lint run

# Check for common issues
go vet ./...

See Also

• •go-linting: Automated tooling for style enforcement
• •go-style-core: Core Go style principles
• •go-documentation: Documentation and comment standards
• •go-error-handling: Error handling patterns
• •go-naming: Naming conventions
• •go-packages: Package design and imports
• •go-interfaces: Interface design patterns
• •go-concurrency: Concurrency patterns
• •go-context: Context usage patterns
• •go-data-structures: Data structure idioms
• •go-defensive: Defensive programming
• •go-testing: Testing patterns
• •go-performance: Performance considerations