golang

name	golang
description	Go, golang, .go, go.mod, gofmt, go test -> use when editing, reviewing, or implementing Go code.

Golang

Prefer repository-local conventions, package structure, naming, and test style before applying general guidance.

Design and packages

• Keep designs simple and explicit; favor clear functions and concrete types over premature abstractions.
• Define small interfaces at the consumer boundary, not broad provider-owned interfaces.
• Respect package boundaries: avoid cycles, keep exported APIs minimal, and put domain behavior near the data it owns.
• Use dependency injection where it improves testability, but avoid framework-heavy patterns unless already present.

Errors and context

• Return errors instead of panicking except for programmer errors or initialization failures that cannot be recovered.
• Add context with fmt.Errorf("...: %w", err) when crossing boundaries; preserve sentinel errors for errors.Is/errors.As.
• Accept context.Context for request-scoped work, I/O, RPC, database calls, and goroutines that need cancellation.
• Check cancellation in long-running loops and propagate contexts rather than creating detached background work.

Concurrency

• Prefer simple ownership of data over shared mutable state; protect shared state with channels, mutexes, or atomics as appropriate.
• Ensure goroutines have clear lifetimes and error/cancellation paths; avoid leaks and unbounded fan-out.
• Be explicit about channel close ownership and avoid sending on channels from multiple uncontrolled writers.

Testing and tooling

• Use table-driven tests for meaningful input/output matrices and name cases clearly.
• Test observable behavior and edge cases; avoid brittle tests tied to incidental implementation details.
• Run or suggest the narrowest relevant checks: gofmt, go test ./... or targeted packages, go vet, and staticcheck when the repo uses it.
• Keep generated code, mocks, and fixtures aligned with existing repository tooling.