C# operator precedence and evaluation order explained
A walkthrough of how C# actually reads an expression: precedence and associativity fix the grouping, while operand evaluation still runs left to right. The article uses logged method calls, subtraction, null coalescing chains and short-circuiting to show where each rule applies and where intuition goes wrong.
Key points
- Precedence decides how an expression groups; it does not reorder method calls, because operands are evaluated left to right.
- Associativity only matters inside one precedence level: subtraction groups left, assignment, null coalescing and the conditional operator group right.
- A right-associative `??` chain still evaluates its leftmost operand first and skips later ones once a non-null value is found.
- Parentheses fix structure, not execution order; if you need a visible sequence, split the expression into separate statements.
- `&&` binds tighter than `||`, so the grouping must be settled before reasoning about which branch short-circuits.
- An exception in an early operand stops evaluation of later operands, and asynchronous invocation order says nothing about completion order.
Operator precedence and operand evaluation order are two different rules in C#, and mixing them up produces explanations that are simply wrong. Nick Cosentino walks through the distinction on a .NET 10 / C# 14 baseline: grouping is decided by the grammar, while operand expressions are still evaluated left to right. A call on the left of an expression therefore runs before a higher-precedence multiplication on its right, even though the multiplication groups tighter.
The article then separates associativity from execution order. Subtraction is left-associative, null coalescing is right-associative, yet a `??` chain still tests its leftmost operand first and skips the rest once a value is found; C# 14's null-conditional assignment follows the same conditional logic. Short-circuiting `&&` and `||`, operator families that mix arithmetic with comparisons, and expressions with side effects all get the same treatment, with a review loop that starts from the innermost subexpression and only trusts examples where competing interpretations give different results.
Real-world use
- Reviewing a pull request where a null coalescing chain looks like it runs right to left but actually tests the leftmost value first.
- Simplifying an authorization condition that mixes `&&` and `||` so the grouping matches the written policy.
- Debugging a log sequence that shows a method call on the left running before a higher-precedence operation on the right.
- Deciding when a dense expression with property getters and assignments should be split into separate statements during refactoring.
Why it matters
Misreading the two rules leads to wrong assumptions about what code actually executes, which is exactly where skipped validation, unintended side effects and confusing bugs come from.