alguidelines.dev - Business Central Design Patterns – Design

Docs: By Reference Parameters

Mon, 01 Jan 0001 00:00:00 +0000

Do not declare parameters by reference if their values are not intended to be changed.

Unintentional value changes might propagate. Also, it might lead people to believe that value changes are intended.

Bad code

LOCAL PROCEDURE ShowMessage@15(VAR Text@1000 : Text[250]);
BEGIN
Text := GetMessageText;
IF (Text <> '') AND GenJnlLineInserted THEN
MESSAGE(Text);
END;

Good code

LOCAL PROCEDURE ShowMessage@15(Text@1000 : Text[250]);
BEGIN
Text := GetMessageText;
IF (Text <> '') AND GenJnlLineInserted THEN
MESSAGE(Text);
END;

Docs: Class Coupling

Mon, 01 Jan 0001 00:00:00 +0000

Do not write functions that have high class coupling. This makes the code hard to maintain.

Bad code

Any procedure / trigger that has class coupling of > 30

Good code

Any procedure / trigger that has class coupling of <= 30\.
Class coupling is computed by summing the unique instances of the following in a code block:
- every unique usage of a complex C/AL data type (table, codeunit, etc) as 1\.
- every unique usage of a DotNet type as 1\.

Docs: Cyclomatic Complexity

Mon, 01 Jan 0001 00:00:00 +0000

Do not write functions that have high cyclomatic complexity. This makes the code hard to maintain.

Bad code

Any procedure / trigger that has a cyclomatic complexity > 25, using the CC3 version mentioned in [this article][anchor0].

Good code

Any procedure / trigger that has a cyclomatic complexity <= 25, using the CC3 version.
The CC3 version is computed by summing the following in a code block:
- each IF statement as 1\.
- each entire CASE as 1\.

Docs: Encapsulate Local Functionality

Mon, 01 Jan 0001 00:00:00 +0000

Any function used local must be defined as local.

Docs: FINDSET FINDFIRST FINDLAST

Mon, 01 Jan 0001 00:00:00 +0000

FINDSET, FIND(’+’) or FIND(’-’) should only be used when NEXT is used and vice versa.

Bad code

IF Cust.FIND('-') THEN
ERROR(CustIsBlockErr)

Good code

IF Cust.FINDFIRST THEN
ERROR(CustIsBlockErr)

Bad code

IF Cust.FINDFIRST THEN
REPEAT
...
UNTIL Cust.NEXT = 0;

Good code

IF Cust.FINDSET THEN
REPEAT
...
UNTIL Cust.NEXT = 0;

Docs: Initialized Variables

Mon, 01 Jan 0001 00:00:00 +0000

Variables should always be set to a specific value, before they are used.

Bad code

PROCEDURE SetPurchLine@22(VAR CurrentPurchLine@1000 : Record 39);
VAR
Pegging@1001 : Boolean;
BEGIN
IF Pegging THEN
CurrQuantity := CurrentPurchLine."Quantity (Base)"
ELSE
CurrQuantity := CurrentPurchLine."Outstanding Qty. (Base)";
END;

Good code

PROCEDURE SetPurchLine@22(VAR CurrentPurchLine@1000 : Record 39);
VAR
Pegging@1001 : Boolean;
BEGIN
Pegging := IsPegging(CurrentPurchLine);
IF Pegging THEN
CurrQuantity := CurrentPurchLine."Quantity (Base)"
ELSE
CurrQuantity := CurrentPurchLine."Outstanding Qty. (Base)";
END;

Bad code

// In the example below, the function will always return FALSE.
PROCEDURE GetItemsToPlan@22() : Boolean;
BEGIN
SETRANGE("Document Type","Document Type"::Order);
...
FINDSET
END;

Good code

PROCEDURE GetItemsToPlan@22() : Boolean;
BEGIN
SETRANGE("Document Type","Document Type"::Order);
...
EXIT(FINDSET)
END;

Docs: Maintainability Index

Mon, 01 Jan 0001 00:00:00 +0000

Maintainability Index: Do not write functions that have a very low maintainability index. This makes the code hard to maintain.

Bad code

Any procedure / trigger that has a maintainability index < 20

Good code

Any procedure / trigger that has a maintainability index >= 20\.
The Maintainability Index is computed as a function:
- Lines Of Code (inverse proportional)
- the Halstead Volume
- Cyclomatic Complexity (inverse proportional).

More info

Bad code

Any procedure / trigger that is > 100 lines of code

Good code

Any procedure / trigger that is <= 100 lines of code.
A full C/AL Statement counts as 1 line of code

Docs: Parameter Placeholders

Mon, 01 Jan 0001 00:00:00 +0000

The number of parameters passed to a string must match the placeholders.

Bad code

CannotDeleteLineErr@1005 : TextConst 'ENU=You cannot delete this line because one or more rating values exists.';
...
ERROR(CannotDeleteLineErr,TABLECAPTION);

Good code

CannotDeleteLineErr@1005 : TextConst 'ENU=You cannot delete this line because one or more rating values exists.';
...
ERROR(CannotDeleteLineErr);

Bad code

CannotUseThisFieldErr@1020 : TextConst 'ENU=You cannot use this field for %2 fields.';
...
ERROR(CannotUseThisFieldErr,0,Field.Class);

Good code

CannotUseThisFieldErr@1020 : TextConst 'ENU=You cannot use this field for %1 fields.';
...
ERROR(CannotUseThisFieldErr,Field.Class);

Docs: Static Object Invocation

Mon, 01 Jan 0001 00:00:00 +0000

Call objects statically whenever possible. It reduces extra noise and removes extra variables. Downside: changing the name of the object which is called statically will need a code update.

Bad code

LOCAL PROCEDURE Code@1();
VAR
CAJnlPostBatch@1001 : Codeunit 1103;
BEGIN
CAJnlPostBatch.Run(CostJnlLine);
END;

Good code

LOCAL PROCEDURE Code@1();
BEGIN
CODEUNIT.RUN(CODEUNIT::"CA Jnl.-Post Batch",CostJnlLine);
END;

Docs: Unreachable Code

Mon, 01 Jan 0001 00:00:00 +0000

Do not write code that will never be hit.

It affects code readability and can lead to wrong assumptions.

Bad code

IF Type <> Type::FIELD THEN BEGIN
...
ERROR(...);
RecRef.CLOSE;
END;

Good code

IF Type <> Type::FIELD THEN BEGIN
...
RecRef.CLOSE;
ERROR(...);
END;

Docs: Unused Initialized Variables

Mon, 01 Jan 0001 00:00:00 +0000

The value assigned to a variable must be used. Else the variable is not necessary.

Bad code

PROCEDURE AddEntities@1(FilterStr@1000 : Text[250]);
VAR
Vendor@1001 : Record 23;
Count@1002 : Integer;
BEGIN
Count := 0;
Vendor.SETFILTER("No.",FilterStr);
IF Vendor.FINDSET THEN
REPEAT
"User ID" := USERID;
"Vendor No." := Vendor."No.";
IF INSERT THEN
Count += 1;
UNTIL Vendor.NEXT = 0;
END;

Good code

PROCEDURE AddEntities@1(FilterStr@1000 : Text[250]);
VAR
Vendor@1001 : Record 23;
BEGIN
Vendor.SETFILTER("No.",FilterStr);
IF Vendor.FINDSET THEN
REPEAT
"User ID" := USERID;
"Vendor No." := Vendor."No.";
IF INSERT THEN;
UNTIL Vendor.NEXT = 0;
END;

Docs: Unused Variables

Mon, 01 Jan 0001 00:00:00 +0000

Do not declare variables that are unused.

Unused variables affect readability.

Bad code

PROCEDURE CheckPostingDate@23(CaptionEntryNo@1005 : Text[50]);
BEGIN
IF GenJnlCheckLine.DateNotAllowed(PostingDate) THEN
ERROR(DateNotAllowedErr,Caption,EntryNo)
IF PostingDate > MaxPostingDate THEN
MaxPostingDate := PostingDate;
END

Good code

PROCEDURE CheckPostingDate@23();
BEGIN
IF GenJnlCheckLine.DateNotAllowed(PostingDate) THEN
ERROR(DateNotAllowedErr,Caption,EntryNo);
IF PostingDate > MaxPostingDate THEN
MaxPostingDate := PostingDate;
END;

Bad code

PROCEDURE IsReturned@14(EntryNo@1002 : Integer) : Decimal;
VAR
ItemEntry@1000 : Record 32;
Quantity@1003 : Integer;
BEGIN
EXIT(-OutboundApplied(EntryNo,TRUE) - InboundApplied(EntryNo,TRUE));
END;

Good code

PROCEDURE IsReturned@14(EntryNo@1002 : Integer) : Decimal;
BEGIN
EXIT(-OutboundApplied(EntryNo,TRUE) - InboundApplied(EntryNo,TRUE));
END;

Docs: Variable Capacity Mismatch

Mon, 01 Jan 0001 00:00:00 +0000

Do not assign a value to a variable whose capacity is smaller.

It will throw an error at runtime.

Bad code

FileName@1010 : Text[250];
...
UploadedFileName@1016 : Text[1024];
...
FileName := UploadedFileName;

Good code

FileName@1010 : Text[1024];
...
UploadedFileName@1016 : Text[1024];
...
FileName := UploadedFileName;

Bad code

FileName@1010 : Text[250];
...
UploadedFileName@1016 : Text[1024];
...
FileName := UploadedFileName;

Good code

FileName@1010 : Text[250];
...
UploadedFileName@1016 : Text[1024];
...
FileName := COPYSTR(UploadedFileName,1,250); // In case only the first 250 chars are needed. Similar for fields

Bad code

VAR
ExceededNumberTxt@001 : 'ENU=Warning: Exceeded number of unsent documents/requests'
Subject@1002 : Text[50];
...
BEGIN
...
Subject := ExceededNumberTxt;

Good code

VAR
ExceededNumberTxt@001 : 'ENU=Warning: Exceeded number of unsent documents/requests'
Subject@1002 : Text[100];
...
BEGIN
...
Subject := ExceededNumberTxt';

Docs: WITH Scope Name Collision

Mon, 01 Jan 0001 00:00:00 +0000

Do not use the WITH scope when it has a variable whose name is the same as a local variable. This can lead to wrong code assumptions.

Given that
“Contract Type” is a field on table ServiceContractHeader, then in the following example there is a parameter name clash with the field name. Which one will be used?

Bad code

PROCEDURE InsertData@1("Contract Type"@1000 : Option...);
...
BEGIN
...
WITH ServiceContractHeader DO BEGIN
...
DimMgt.InsertServContractDim(...,"Contract Type","Contract No.",0,...);
END;

Good code

PROCEDURE InsertData@1(ContractType@1000 : Option...);
...
BEGIN
...
WITH ServiceContractHeader DO BEGIN
...
DimMgt.InsertServContractDim(...,ContractType,"Contract No.",0,...);
END;