Order of evaluation
Go does not guarantee every subexpression order people casually assume; side effects inside one expression need care.
Canonical guidance
- not every operand evaluation detail is left-to-right in the way people casually expect
- assignments and calls with side effects deserve caution
- separate statements are usually better than clever packed expressions
Use when
- reviewing side-effectful expressions
- debugging surprising results from indexing, appending, or assignment
- checking whether a refactor changed semantics
Avoid
- combining mutation and observation of the same value in one dense expression
- depending on unspecified sequencing
- hiding important state changes inside call arguments
Preferred pattern
next := f()
s[i] = next
Anti-pattern
- relying on multiple side effects within one expression whose sequencing is not obvious from the spec
Explanation: This is tempting because it is compact, but expression compression is not worth semantic ambiguity.
Why
- order-of-evaluation bugs are hard to review because the code often looks reasonable until the exact rule matters