common iota mistakes in Go

A common mistake is assuming the number produced by iota will remain stable forever. The value depends on a constant's position in its const block, so inserting another specification above it changes the generated number even though the constant's name and type remain unchanged.

For example, suppose Pending, Running, and Done are stored as zero, one, and two in a database. If Paused is later inserted between Pending and Running, Running becomes two and Done becomes three. Old rows are then interpreted as the wrong states, and the compiler cannot detect that compatibility problem.

I prevent this by assigning explicit values whenever constants cross a process boundary or are persisted: Pending State = 0, Running State = 1, and Done State = 2. iota is safer for private implementation details where renumbering has no external effect.

Another subtle point is that iota advances for every constant specification, including a line that uses the blank identifier. In const (_ = iota; KB = 1 << (10 * iota)), the first line deliberately consumes zero, so KB uses one. Removing that placeholder changes the calculation.

The zero value also deserves attention. If zero means a valid state such as Pending, an uninitialized variable silently has that state. Sometimes that is useful, but sometimes I reserve zero as Unknown so missing initialization is visible instead of being treated as a legitimate business value.

I would test the actual numeric values when they form a contract, not only their printed names. A focused test that asserts Running == 1 and Done == 2 catches accidental renumbering during review.

The key rule is that iota removes repetitive numbering, but it does not promise stable numbering. I choose it only when that trade-off is acceptable.