mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 22:56:55 +01:00
53ecca3204
The AL Guidelines mark `SetLoadFields` placed before `SetRange`/`SetFilter` as bad code and recommend filters first, while the BCQuality samples used the opposite order — contradictory guidance across two Microsoft repos. Per Learn (`Record.SetLoadFields`), "fields that are filtered upon are always loaded", so the two orders produce an identical projection. The upstream rule is a readability convention: keep `SetLoadFields` adjacent to the read it governs. - Reorder filters ahead of `SetLoadFields` in the six affected AL samples. - State the placement convention in the Best Practice section. - Record in Description that order does not change the projection, and that only a fieldless `SetLoadFields()` or a later overwriting call does. - Add an Anti Pattern note so review agents treat the reverse order as a readability observation, never a performance defect. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
23 lines
678 B
AL
23 lines
678 B
AL
codeunit 50218 "Perf Sample LoadFields Good"
|
|
{
|
|
procedure ListUSCustomerNames()
|
|
var
|
|
Customer: Record Customer;
|
|
begin
|
|
Customer.SetRange("Country/Region Code", 'US');
|
|
Customer.SetLoadFields(Name);
|
|
if Customer.FindSet() then
|
|
repeat
|
|
Message(Customer.Name);
|
|
until Customer.Next() = 0;
|
|
end;
|
|
|
|
procedure LookupSkuPolicy(LocationCode: Code[10]) Policy: Enum "SKU Creation Method"
|
|
var
|
|
Location: Record Location;
|
|
begin
|
|
Location.SetLoadFields("SKU Creation Policy");
|
|
if Location.Get(LocationCode) then
|
|
Policy := Location."SKU Creation Policy";
|
|
end;
|
|
}
|