For-select loops

Canonical guidance

• keep each select arm meaningful
• include shutdown handling in long-lived loops
• nil channels deliberately when you need to disable a case

Use when

• event loops
• brokers and dispatchers
• multiplexed worker control paths

Avoid

• default cases that busy-spin
• mixing too many unrelated responsibilities in one loop
• relying on select fairness for correctness

Preferred pattern

for {
	select {
	case <-ctx.Done():
		return ctx.Err()
	case item, ok := <-in:
		if !ok {
			return nil
		}
		handle(item)
	}
}

Anti-pattern

• a for-select loop with no cancel path and a default that polls constantly

Explanation: This is tempting because it feels responsive, but it burns CPU and still fails to model lifecycle cleanly.

Why

• most select-loop bugs are lifecycle or progress bugs