go-code-review

name	go-code-review
description	Quick-reference checklist for Go code review based on the Go Wiki CodeReviewComments. Maps to detailed skills for comprehensive guidance. Use when reviewing Go code or checking code against community style standards.

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