Go Code Review

Go Code Review Checklist

Compatibility: references/WEB-SERVER.md uses log/slog examples that require Go 1.21+.

Resource Routing

• assets/review-template.md - Use when formatting review output with Must Fix, Should Fix, and Nits sections.
• scripts/pre-review.sh - Run before manual review to collect gofmt, go vet, and golangci-lint results.
• references/WEB-SERVER.md - Read when reviewing an HTTP server that combines concurrency, context, logging, error handling, and shutdown behavior.

Review Procedure

Use assets/review-template.md when formatting the output of a code review to ensure consistent structure with Must Fix / Should Fix / Nits severity grouping.

1. Run gofmt -d . and go vet ./... to catch mechanical issues first
2. Read the diff file-by-file; for each file, check the categories below in order
3. Flag issues with specific line references and the rule name
4. After reviewing all files, re-read flagged items to verify they're genuine issues
5. Summarize findings grouped by severity (must-fix, should-fix, nit)

Validation: After completing the review, re-read the diff once more to verify every flagged issue is real. Remove any finding you cannot justify with a specific line reference.

---

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
• Avoid built-in names: Don't shadow error, string, len, cap, append, copy, new, make → go-declarations

---

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

---

Declarations and Initialization

• Group similar: Related var/const/type in parenthesized blocks; separate unrelated → go-declarations
• var vs :=: Use var for intentional zero values; := for explicit assignments → go-declarations
• Reduce scope: Move declarations close to usage; use if-init to limit variable scope → go-declarations
• Struct init: Always use field names; omit zero fields; var for zero structs → go-declarations
• Use any: Prefer any over interface{} in new code → go-declarations

---