alguidelines.dev - Business Central Design Patterns – Readability

Docs: Begin as an 'After Word'

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

When BEGIN follows THEN, ELSE, DO, it should be on the same line, preceded by one space character.

Bad code

IF ICPartnerRefType = ICPartnerRefType::"Common Item No." THEN
 BEGIN
 ...
END;

Good code

IF ICPartnerRefType = ICPartnerRefType::"Common Item No." THEN BEGIN
...
END;

Docs: Begin-End - Compound Only

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

Only use BEGIN..END to enclose compound statements.

Bad code

IF FINDSET THEN BEGIN
 REPEAT
 ...
 UNTIL NEXT = 0;
END;

Good code

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

Bad code

IF IsAssemblyOutputLine THEN BEGIN
 TESTFIELD("Order Line No.",0);
END;

Good code

IF IsAssemblyOutputLine THEN
 TESTFIELD("Order Line No.",0);

Bad code

IF FINDSET THEN
 REPEAT
 BEGIN
 ...
 END;
 UNTIL NEXT = 0;

Good code

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

Exception

// Except for this case
IF X THEN BEGIN
 IF Y THEN
 DO SOMETHING;
END ELSE (not X)

Docs: Binary Operator to Start Line

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

Do not start a line with a binary operator.

Bad code

"Quantity to Ship" :=
 Quantity
 - "Quantity Shipped"

Good code

"Quantity to Ship" :=
 Quantity -
 "Quantity Shipped"

Docs: Blank Lines

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

Do not use blank lines at the beginning or end of any functions, after BEGIN, before END, or inside multiline expressions.

Bad code

PROCEDURE MATRIX_OnDrillDown@1133(MATRIX_ColumnOrdinal : Integer);
BEGIN

 SetupDrillDownCol(MATRIX_ColumnOrdinal);
 DrillDown(FALSE,ValueType);

END;

Good code

PROCEDURE MATRIX_OnDrillDown@1133(MATRIX_ColumnOrdinal : Integer);
BEGIN
 SetupDrillDownCol(MATRIX_ColumnOrdinal);
 DrillDown(FALSE,ValueType);
END;

Bad code

IF NameIsValid AND

 Name2IsValid
THEN

Good code

IF NameIsValid AND
 Name2IsValid
THEN

Docs: CASE Action

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

A CASE action should start on a line after the possibility.

Bad code

CASE Letter OF
 'A': Letter2 := '10';
 'B': Letter2 := '11';

Good code

CASE Letter OF
 'A':
 Letter2 := '10';
 'B':
 Letter2 := '11';

Docs: Colon usage in CASE

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

The last possibility on a CASE statement must be immediately followed by a colon.

Bad code

CASE DimOption OF
 DimOption::"Global Dimension 1" :
 DimValue."Dimension Code" := GLSetup."Global Dimension 1 Code";

Good code

CASE DimOption OF
 DimOption::"Global Dimension 1":
 DimValue."Dimension Code" := GLSetup."Global Dimension 1 Code";

Docs: Comments inside Curly Brackets

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

Never use curly bracket comments. During development, the “Block comment” functionality can be used instead. However, in production code, block comments are not recommended.

Bad code

PeriodTxt: {Period}

Good code

PeriodTxt: // Period

Bad code

PROCEDURE MATRIX_OnAfterGetRecord@10(MATRIX_ColumnOrdinal : Integer);
BEGIN
 {
 IF ShowColumnName THEN
 MatrixHeader := MatrixRecords[MATRIX_ColumnOrdinal].Name
 ELSE
 MatrixHeader := MatrixRecords[MATRIX_ColumnOrdinal].Code;
 }
 MatrixRecord := MatrixRecords[MATRIX_ColumnOrdinal];
 AnalysisValue := CalcAmt(ValueType,TRUE);
 MATRIX_CellData[MATRIX_ColumnOrdinal] := AnalysisValue;
END;

Good code

PROCEDURE MATRIX_OnAfterGetRecord@10(MATRIX_ColumnOrdinal : Integer);
BEGIN
 MatrixRecord := MatrixRecords[MATRIX_ColumnOrdinal];
 AnalysisValue := CalcAmt(ValueType,TRUE);
 MATRIX_CellData[MATRIX_ColumnOrdinal] := AnalysisValue;
END;

Docs: Comment Spacing

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

Always start comments with // followed by one space character.

Bad code

RowNo += 1000; //Move way below the budget

Good code

RowNo += 1000; // Move way below the budget

Docs: END ELSE Pair

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

The END ELSE pair should always appear on the same line.

Bad code

IF OppEntry.FIND('-') THEN
 IF SalesCycleStage.FIND('-') THEN BEGIN
 ...
 END
ELSE
 ...

Good code

IF OppEntry.FIND('-') THEN
 IF SalesCycleStage.FIND('-') THEN BEGIN
 ...
END ELSE
 ...

Docs: Indentation

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

In general, use an indentation of two space characters. Logical expressions in the IF, WHILE, and UNTIL parts are indented at least 3, 6, and 6 spaces respectively.

Bad code

IF GLSetup."Unrealized VAT" OR
 (GLSetup."Prepayment Unrealized VAT" AND NewCVLedgEntryBuf.Prepayment)

Good code

IF GLSetup."Unrealized VAT" OR
 (GLSetup."Prepayment Unrealized VAT" AND NewCVLedgEntryBuf.Prepayment)

Bad code

IF GenJnlLine."Account No." <> ICPartner.Code THEN
 ICPartner.GET("Account No.");
 IF GenJnlLine.Amount \> 0 THEN BEGIN
 ...

Good code

IF GenJnlLine."Account No." <> ICPartner.Code THEN
 ICPartner.GET("Account No.");
IF GenJnlLine.Amount > 0 THEN BEGIN
 ...

Bad code

Dialog.OPEN(WindowTxt +
 '@1@@@@@@@@@@@@@@@@@@@@@@@');

Good code

Dialog.OPEN(
 WindowTxt +
 '@1@@@@@@@@@@@@@@@@@@@@@@@');

Bad code

TempOldCustLedgEntry.DELETE;
 // Find the next old entry for application of the new entry

Good code

TempOldCustLedgEntry.DELETE;
// Find the next old entry for application of the new entry

Bad code

IF NOT ("Applies-to Doc. Type" IN
 ["Applies-to Doc. Type"::Receipt,
 "Applies-to Doc. Type"::"Return Shipment"])

Good code

IF NOT ("Applies-to Doc. Type" IN
 ["Applies-to Doc. Type"::Receipt,
 "Applies-to Doc. Type"::"Return Shipment"])

Bad code

WHILE (RemAmt > 0) OR
 (RemAmtLCY > 0)
DO

Good code

WHILE (RemAmt > 0) OR
 (RemAmtLCY > 0)
DO

Bad code

UNTIL (RemAmt > 0) AND
 (RemAmtLCY > 0);

Good code

UNTIL (RemAmt > 0) AND
 (RemAmtLCY > 0)

Docs: Keyword Pairs - Indentation

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

The IF..THEN pair, WHILE..DO pair, and FOR..DO pair must appear on the same line or the same level of indentation.

Bad code

IF (x = y) AND
 (a = b) THEN

Good code

IF (x = y) AND
 (a = b)
THEN

Docs: Line Start Keywords

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

The END, IF, REPEAT, FOR, WHILE, ELSE and CASE statement should always start a line.

Bad code

IF IsContactName THEN ValidateContactName
 ELSE IF IsSalespersonCode THEN ValidateSalespersonCode
 ELSE IF IsSalesCycleCode THEN ValidatSalesCycleCode;

Good code

IF IsContactName THEN
 ValidateContactName
ELSE
 IF IsSalespersonCode THEN
 ValidateSalespersonCode
 ELSE
 IF IsSalesCycleCode THEN
 ValidatSalesCycleCode;

Docs: Lonely Repeat

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

The REPEAT statement should always be alone on a line.

Bad code

IF ReservEntry.FINDSET THEN REPEAT

Good code

IF ReservEntry.FINDSET THEN
 REPEAT

Docs: Named Invocations

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

When calling an object statically use the name, not the number

Bad code

PAGE.RUNMODAL(525,SalesShptLine)

Good code

PAGE.RUNMODAL(PAGE::"Posted Sales Shipment Lines",SalesShptLine)

Docs: Nested WITHs

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

Do not nest WITHs that reference different types of objects.

Bad code

WITH PostedWhseShptLine DO BEGIN
 ...
 WITH ItemLedgEntry DO
 InsertBufferRec(...,"Serial No.","Lot No.",...);
 ...
END;

Good code

WITH PostedWhseShptLine DO BEGIN
 ...
 InsertBufferRec(...,ItemLedgEntry."Serial No.",ItemLedgEntry."Lot No.",...);
 ...
END;

Docs: One Statement Per Line

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

A line of code should not have more than one statement.

Bad code

IF OppEntry.FIND('-') THEN EXIT

Good code

IF OppEntry.FIND('-') THEN
 EXIT

Bad code

TotalCost += Cost; TotalAmt += Amt;

Good code

TotalCost += Cost;
TotalAmt += Amt;

Docs: Separate IF and ELSE

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

IF and ELSE statements should be on separate lines.

Bad code

IF Atom[i+1] = '>' THEN HasLogicalOperator := TRUE ELSE BEGIN
 ...
END;

Good code

IF Atom[i+1] = '>' THEN
 HasLogicalOperator := TRUE
ELSE BEGIN
 ...
END;

Docs: Spacing Binary Operators

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

There must be exactly one space character on each side of a binary operator such as = + - AND OR =. The parameter comma operator however, should have no spaces.

Bad code

"Line Discount %" := "Line Discount Amount"/"Line Value"*100

Good code

"Line Discount %" := "Line Discount Amount" / "Line Value" * 100;

Bad code

StartDate := CALCDATE('<+'+FORMAT(Days + i)+'D>', StartDate);

Good code

StartDate := CALCDATE('<+' + FORMAT(Days + i) + 'D>',StartDate);

Bad code

StartDate := 0D; // Initialize

Good code

StartDate := 0D; // Initialize

Docs: Spacing Brackets and ::

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

There must be no spaces characters before and after [] dimension brackets symbols or :: option symbols.

Bad code

A[i] [j] := Amt;

Good code

A[i][j] := Amt;

Bad code

"Currency Exchange Rate"."Fix Exchange Rate Amount" :: Currency:

Good code

"Currency Exchange Rate"."Fix Exchange Rate Amount"::Currency:

Bad code

IF FIND (Which) THEN

Good code

IF FIND(Which) THEN

Docs: Spacing Unary Operators

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

There must be no space between a unary operator and its argument (except for the NOT keyword).

Bad code

IF NOT(Type = Type::Item) THEN

Good code

IF NOT (Type = Type::Item) THEN

Bad code

DiscAmt := - "Discount Amount";

Good code

DiscAmt := -"Discount Amount";

Docs: Suggested Abbreviations

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

Suggested Abbreviations

Whenever possible, do not use abbreviations in variables, functions and objects names.

If there is no other choice, then use the suggestions below.

Abbreviation

Text

Abs

absence

Acc

account

Acc

accounting

Accum

accumulated

Act

action

Activ

activity

Add

additional

Addr

address

Adj

adjust

Adjd

adjusted

Adjmt

adjustment

Agrmt

agreement

Alloc

allocation

Allow

allowance

Alt

alternative

Amt

amount

Amts

amounts

Ans

answer

Appl

applies

Appln

application

Arriv

arrival

Asm

assembly

ATO

assemble to order

Assgnt

assignment

Assoc

associated

Attmt

attachment

Auth

authorities

Auto

automatic

Avail

availability

Avg

average

ba db.

Bal

balance

BOM

bill of materials

Blnkt

blanket

Budg

budget

Buf

buffer

Bus

business

BIM

business interaction management

Buy

buying

Calc

calculate

Calcd

calculated

Calcu

calculation

Cal

calendar

Cap

capacity

CRP

capacity requirements planning

cash flow

cashflow

ctlg

catalog

Cat

Docs: Temporary Variable Naming

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

The name of a temporary variable must be prefixed with the word Temp and not otherwise.

Bad code

JobWIPBuffer@1002 : TEMPORARY Record 1018;

Good code

TempJobWIPBuffer@1002 : TEMPORARY Record 1018;

Bad code

TempJobWIPBuffer@1002 : Record 1018;

Good code

CopyOfJobWIPBuffer@1002 : Record 1018;

Docs: TextConst Suffixes

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

TextConst variable names should have a suffix (an approved three-letter suffix: Msg, Tok, Err, Qst, Lbl, Txt) describing usage.

Bad code

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

Good code

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

Bad code

Text000@1011 : TextConst 'ENU="has been changed (initial a %1: %2= %3, %4= %5)"';
...
SalesLine.FIELDERROR(Type,STRSUBSTNO(Text000,...);
...

Good code

TypeHasBeenChangedErr@1011 : TextConst 'ENU="has been changed (initial a %1: %2= %3, %4= %5)"';
...
SalesLine.FIELDERROR(Type,STRSUBSTNO(TypeHasBeenChangedErr,...);
...

Bad code

Text004@1004 : TextConst 'ENU=Indenting the Job Tasks \#1\#\#\#\#\#\#\#\#\#\#.';
...
Window@1007 : Dialog;
...
 Window.OPEN(Text004);

Good code

IndentingMsg@1004 : TextConst 'ENU=Indenting the Job Tasks \#1\#\#\#\#\#\#\#\#\#\#.';
...
Window@1007 : Dialog;
...
 Window.OPEN(IndentingMsg);

Bad code

Text002@1005 : TextConst 'ENU=You cannot delete a %1 that is used in one or more setup windows.\\ Do you want to open the G/L Account No. Where-Used List Window?';
...
IF CONFIRM(Text002,TRUE,GLAcc.TABLECAPTION) THEN

Good code

OpenWhereUsedWindowQst@1005 : TextConst 'ENU=You cannot delete a %1 that is used in one or more setup windows.\\ Do you want to open the G/L Account No. Where-Used List Window?';
...
IF CONFIRM(OpenWhereUsedWindowQst,TRUE,GLAcc.TABLECAPTION) THEN

Bad code

Selection := STRMENU(Text003,2);
...
Text003@1002 : TextConst 'ENU=&Copy dimensions from BOM,&Retrieve dimensions from components';

Good code

 Selection := STRMENU(CopyFromQst,2);
 ...
 CopyFromQst@1002 : TextConst 'ENU=&Copy dimensions from BOM,&Retrieve dimensions from components';

Bad code

DATASET
{
...
 { 1 ;1 ;Column ;Chart_of_AccountsCaption;
 SourceExpr=Chart_of_AccountsCaption }
...
Chart_of_AccountsCaption@9647 : TextConst 'ENU=Chart of Accounts';

Good code

DATASET
{
...
 { 1 ;1 ;Column ;Chart_of_AccountsCaption;
 SourceExpr=ChartOfAccountsLbl }
...
ChartOfAccountsLbl@9647 : TextConst 'ENU=Chart of Accounts';

Docs: Unary Operator Line End

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

Do not end a line with unary operator.

Bad code

"Quantity Handled (Base)" := -
 "Quantity Handled (Base)");

Good code

"Quantity Handled (Base)" :=
 - "Quantity Handled (Base)");

Docs: Unnecessary Compound Parenthesis

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

Use parenthesis only to enclose compound expressions inside compound expressions.

Bad code

IF ("Costing Method" = "Costing Method"::Standard) THEN

Good code

IF "Costing Method" = "Costing Method"::Standard THEN

Bad code

ProfitPct = -(Profit) / CostAmt * 100;

Good code

ProfitPct = -Profit / CostAmt * 100;

Docs: Unnecessary ELSE

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

ELSE should not be used when the last action in the THEN part is an EXIT, BREAK, SKIP, QUIT, ERROR.

Bad code

IF IsAdjmtBinCodeChanged THEN
 ERROR(AdjmtBinCodeChangeNotAllowedErr,...)
ELSE
 ERROR(BinCodeChangeNotAllowedErr,...);

Good code

IF IsAdjmtBinCodeChanged THEN
 ERROR(AdjmtBinCodeChangeNotAllowedErr,...)
ERROR(BinCodeChangeNotAllowedErr,...);

Docs: Unnecessary Function Parenthesis

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

Do not use parenthesis in a function call if the function does not have any parameters.

Bad code

IF ReservMgt.IsPositive() THEN

Good code

IF ReservMgt.IsPositive THEN

Bad code

IF ChangeStatusForm.RUNMODAL() <> ACTION::Yes THEN

Good code

IF ChangeStatusForm.RUNMODAL <> ACTION::Yes THEN

Docs: Unnecessary Separators

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

There should be no unnecessary separators.

Bad code

IF Customer.FINDFIRST THEN;;

Good code

IF Customer.FINDFIRST THEN;

Docs: Unnecessary TRUE/FALSE

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

Do not use TRUE or FALSE keywords unnecessarily if the expression is already an logical expression.

Bad code

IF IsPositive() = TRUE THEN

Good code

IF IsPositive THEN

Bad code

IF Complete <> TRUE THEN

Good code

IF NOT Complete THEN

Docs: Variable Already Scoped

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

Do not use scope ‘’.’’ qualifier unnecessarily when a variable is already implicitly or explicitly scoped. It keeps the code simpler.

Bad code

ReturnRcptHeader.SETRANGE(ReturnRcptHeader."Return Order No.","Document No.");

Good code

ReturnRcptHeader.SETRANGE("Return Order No.","Document No.");

Bad code

WITH ChangeLogSetupTable DO BEGIN
 ...
 IF ChangeLogSetupTable.DELETE THEN
 ...
END;

Good code

WITH ChangeLogSetupTable DO BEGIN
 ...
 IF DELETE THEN
 ...
END;

Docs: Variable Naming

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

Variables that refer to a C/AL object must contain the objects name, abbreviated where necessary.

A variable must begin with a capital letter.

Blanks, periods, and other characters (such as parentheses) that would make quotation marks around a variable necessary must be omitted.

If a variable is a compound of two or more words or abbreviations, each word or abbreviation should begin with a capital letter.

Bad code

...
 WIPBuffer@1002 : Record 1018
...
OBJECT Table Job WIP Buffer

Good code

...
 JobWIPBuffer@1002 : Record 1018
...
OBJECT Table Job WIP Buffer

Bad code

...
 Postline@1004 : Codeunit 12;
...
OBJECT Codeunit Gen. Jnl.-Post Line

Good code

...
 GenJnlPostLine@1004 : Codeunit 12;
...
OBJECT Codeunit Gen. Jnl.-Post Line

Bad code

LOCAL PROCEDURE HandleCustDebitCredit@17(...;"Amount (LCY)"@1001 : Decimal;...);
BEGIN
 IF ((... ("Amount (LCY)" \> 0)) ...) OR
 ((... ("Amount (LCY)" < 0)) ...)
 THEN BEGIN
 ...

Good code

LOCAL PROCEDURE HandleCustDebitCredit@17(...;AmountLCY@1001 : Decimal;...);
BEGIN
 IF ((... (AmountLCY \> 0)) ...) OR
 ((... (AmountLCY < 0)) ...)
 THEN BEGIN
 ...

Docs: Variables Declarations Order

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

Variables declarations should be ordered by type. In general, object and complex variable types are listed first followed by simple variables. The order should be the same as the object list in the object designer for C/AL objects. Afterwards come the complex variables like RecordRef, .NET, FieldRef etc. At the end come all the simple data types in no particular order.

Bad code

StartingDateFilter@1002 : Text[30];
Vend@1003 : Record 23;

Good code

Vend@1003 : Record 23;
StartingDateFilter@1002 : Text[30];