Keep each example focused on one design decision. A pattern should solve a visible problem; interfaces and wrappers added only to resemble a class diagram make the example harder to learn from.
For a new example, include a short package comment, a real use case, an executable
Example with expected output and behavior tests. Explain ownership, error
handling and concurrency assumptions. Prefer the standard library and preserve
Go 1.22.5 compatibility.
For a bug fix, add a regression that fails on the old implementation. Tests must be deterministic, run offline and use temporary directories for files. Exercise errors from dependencies, not just the happy path. Do not include API keys or require live services.
Before sending changes:
gofmt -w path/to/changed.go
go vet ./...
go build ./...
go test -count=3 -shuffle=on ./...
go test -race ./...Update the catalog and guide when adding or moving an example. Use a commit message that describes the behavior changed; keep unrelated fixes separate.