Anti-patterns

Solutions that look reasonable but cause problems. First the Go-specific traps, then the classics that apply everywhere.

Anti-pattern

Do this instead

✕ Goroutine leaks

✓ Every goroutine needs an exit path: a closed channel, a cancelled context or a done signal.

✕ Ignoring errors with _

✓ Handle or return the error; if you truly ignore it, add a comment explaining why.

✕ panic for normal control flow

✓ Return errors. Reserve panic for programmer bugs and recover only at boundaries.

✕ Interfaces defined before they are needed

✓ Start with concrete types; extract an interface when a second implementation or a test needs it.

✕ Mutable package-level globals

✓ Pass dependencies explicitly via structs; globals make tests order-dependent.

One class knows and does too much. Split it by responsibility (SRP).

Tangled control flow with no structure. Refactor into small functions with clear inputs and outputs.

Using one familiar tool or pattern for every problem. Pick the simplest fit.

Optimising before measuring. Profile first, then fix the real bottleneck.

Duplicated logic drifts apart. Extract shared code once the duplication is real (rule of three).

Unexplained literals. Use named constants or enums.

Global state disguised as a pattern. Prefer dependency injection with a single-instance lifetime.

Dead or experimental code nobody dares to remove. Delete it; version control remembers.

Saved in this browser only. Part of From code to production (0/5).