Go Idioms Guide

Problem

Go code often diverges less on syntax and more on conventions: how errors are wrapped, where logging happens, whether interfaces are defined near consumers or implementations, and whether goroutines and channels form cancellable, closeable, awaitable structures. In medium-sized modules, these details can make error semantics hard to reason about and raise testing and refactoring costs.

How it works

The skill provides Go idioms rules that can be used as review guidance, generation constraints, or engineering standards:

• Error handling: use fmt.Errorf("context: %w", err) to add context, and use %w to preserve errors.Is / errors.As; use sentinel errors for expected conditions; avoid both logging and returning the same error.
• Interface design: prefer defining interfaces where they are used; favor small, composable interfaces; reuse io.Reader, io.Writer, and fmt.Stringer; name single-method interfaces by method plus er suffix.
• Concurrency patterns: constrain goroutine and channel usage around patterns such as worker pools and channel direction semantics, e.g. jobs <-chan Job as an input channel.

Boundaries

It fits Go services, CLIs, and internal frameworks where review or code generation needs a consistent style. It does not replace architecture decisions; for legacy error codes, business interfaces, or existing concurrency models, combine it with team standards and avoid applying generic idioms blindly to performance-sensitive paths.