Add community knowledge: AL boolean operators do not short-circuit

[António Silva (aacnsilva)]

What

Adds community/knowledge/performance/boolean-operators-do-not-short-circuit.md, with .good.al / .bad.al companions.

AL gives no short-circuit (lazy) evaluation guarantee for and, or, and xor. Code must therefore not use the leftmost operand as a guard for a later one, and must not expect a costly operand to be skipped once the result is decided. The fix is a nested if — guard outermost, dependent or expensive condition inner.

Why this passes the admission test

An LLM trained mostly on C#, JavaScript, or SQL carries short-circuiting in as a default assumption, and BC has no compiler diagnostic that contradicts it. That produces two failure shapes the file prevents:

• A guard that does not guard. (Index >= 1) and (Index <= ArrayLen(Thresholds)) and (Amount > Thresholds[Index]) still evaluates the subscript. Likewise Customer.Get(No) and (Customer.Blocked <> ...) reads Blocked from a record that was never loaded — a silently wrong result rather than an error.
• Cost paid on a path that was already decided — a database call or validation procedure invoked as the right operand of an and whose left operand is already false.

Note on the documentation

Neither AL operators nor Boolean operators mentions short-circuit or lazy evaluation in either direction. The article is therefore worded as no guarantee is given, so do not rely on one, rather than asserting a documented evaluation order. That yields the same guidance without claiming platform behaviour the docs do not state — and is part of why this went to /community/ rather than /microsoft/.

🤖 Generated with Claude Code

[António Silva (aacnsilva)]

Some people prefer to use the in operator to short-circuit/lazy evaluate but AL developers are most used to seeing if statements and the in operator might confuse more than help, at least in the beginning, so I added nested if conditions instead in the knowledge file and good pattern.