go generate

Canonical guidance

• use go generate for explicit source generation
• keep generator commands reproducible and documented
• decide deliberately whether generated output is committed

Use when

• stringers
• mocks or stubs when the repo policy allows them
• code derived from schemas or protocol definitions

Avoid

• hiding generation inside ordinary go build
• undocumented external generator dependencies
• hand-editing generated files

Preferred pattern

//go:generate stringer -type=State
type State int

Anti-pattern

• requiring go generate to make the package compile, but not documenting or enforcing it anywhere

Explanation: This anti-pattern is tempting because it keeps the build “automatic” locally, but it fails unpredictably for everyone else.

Why

• explicit generation is manageable; hidden generation is operational debt