time.After

Canonical guidance

• time.After is fine for simple one-off waits
• prefer time.NewTimer when timeouts repeat or need cleanup control
• stop timers you no longer need

Use when

• one-shot select timeouts
• tests or tiny helpers
• code where timer reuse is irrelevant

Avoid

• time.After inside long-running loops
• creating fresh timers on every iteration without control
• assuming timeout channels can be canceled after creation

Preferred pattern

timer := time.NewTimer(timeout)
defer timer.Stop()

select {
case <-done:
	return nil
case <-timer.C:
	return context.DeadlineExceeded
}

Anti-pattern

• select loops that create a new time.After on every pass

Explanation: This anti-pattern is tempting because it is short, but repeated one-shot timer creation obscures lifecycle costs and cancellation behavior.

Why

• explicit timers make repeated timeout paths easier to reason about