https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/Recent content in Readability on BC AL HelpHugo -- gohugo.ioen-ushttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/begin-as-an-afterword/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/begin-as-an-afterword/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/begin-end/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/begin-end/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 .https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/binary-operator-line-start/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/binary-operator-line-start/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"https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/blank-lines/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/blank-lines/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 THENhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/case-actions/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/case-actions/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';https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/colon-usage-in-case/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/colon-usage-in-case/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";https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/comments-curly-brackets/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/comments-curly-brackets/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/comments-spacing/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/comments-spacing/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 budgethttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/end-else-pair/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/end-else-pair/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 ...https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/indentation/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/indentation/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 codehttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/keyword-pairs-indentation/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/keyword-pairs-indentation/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) THENhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/line-start-keywords/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/line-start-keywords/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/lonely-repeat/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/lonely-repeat/The REPEAT statement should always be alone on a line. Bad code IF ReservEntry.FINDSET THEN REPEAT Good code IF ReservEntry.FINDSET THEN REPEAThttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/named-invocations/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/named-invocations/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)https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/nested-withs/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/nested-withs/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/one-statement-per-line/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/one-statement-per-line/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/separate-if-and-else/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/separate-if-and-else/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-binary-operators/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-binary-operators/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 codehttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-brackets-and/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-brackets-and/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) THENhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-unary-operators/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/spacing-unary-operators/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";https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/suggested-abbreviations/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/suggested-abbreviations/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 Asmhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/temporary-variable-naming/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/temporary-variable-naming/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/textconst-suffixes/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/textconst-suffixes/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)"'; .https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unary-operator-line-end/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unary-operator-line-end/Do not end a line with unary operator. Bad code "Quantity Handled (Base)" := - "Quantity Handled (Base)"); Good code "Quantity Handled (Base)" := - "Quantity Handled (Base)");https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-compound-parenthesis/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-compound-parenthesis/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-else/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-else/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,...);https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-function-parenthesis/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-function-parenthesis/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 THENhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-separators/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-separators/There should be no unnecessary separators. Bad code IF Customer.FINDFIRST THEN;; Good code IF Customer.FINDFIRST THEN;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-truefalse/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/unnecessary-truefalse/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 THENhttps://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variable-already-scoped/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variable-already-scoped/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;https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variable-naming/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variable-naming/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 .https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variables-declarations-order/Mon, 01 Jan 0001 00:00:00 +0000https://bcalhelp.dev/navpatterns/3-cal-coding-guidelines/readability/variables-declarations-order/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