mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
AL gives no short-circuit (lazy) evaluation guarantee for and/or/xor — neither the AL operators nor the boolean operators documentation defines a lazy evaluation order. LLMs trained on C#, JavaScript, or SQL assume the left operand guards the right, which produces conditions where a guard does not protect an unsafe subscript or a field read after a failed Get, and where an expensive operand is paid on every path. Adds community/knowledge/performance/boolean-operators-do-not-short-circuit.md with good/bad AL companions. The guidance prefers nested if when one operand depends on another, while keeping and/or legitimate for operands that are independently safe and cheap, so a reviewer does not flag harmless bound checks. This is the first article in a community performance domain; the Microsoft performance review leaf skill already sources candidates by domain across every enabled layer, so no skill change is needed to reach it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
24 lines
918 B
AL
24 lines
918 B
AL
codeunit 50540 "Perf Sample NoShortCircuit Good"
|
|
{
|
|
procedure ExceedsThreshold(var Thresholds: array[10] of Decimal; Index: Integer; Amount: Decimal): Boolean
|
|
begin
|
|
// 'and' is safe here: both operands are cheap and neither depends on the other.
|
|
if (Index >= 1) and (Index <= ArrayLen(Thresholds)) then
|
|
// The subscript lives in its own if, so it is never evaluated out of range.
|
|
if Amount > Thresholds[Index] then
|
|
exit(true);
|
|
exit(false);
|
|
end;
|
|
|
|
procedure IsBlockedCustomer(CustomerNo: Code[20]): Boolean
|
|
var
|
|
Customer: Record Customer;
|
|
begin
|
|
// The cheap test runs first, and the field is read only after Get succeeded.
|
|
if CustomerNo = '' then
|
|
exit(false);
|
|
if not Customer.Get(CustomerNo) then
|
|
exit(false);
|
|
exit(Customer.Blocked <> Customer.Blocked::" ");
|
|
end;
|
|
}
|