Best Practices for AL

This page defines some of the best practices to follow when writing AL code for Dynamics 365 Business Central. These best practices are additional to rules and guidelines that are caught during compilation of AL code. We recommend following these best practices when developing extensions in AL to ensure consistency and discoverability on file, object, and method naming, as well as better readability of written code.


If a best practice is not mentioned here, the PreCal rules listed here apply.

Extension structure

An extension is fully contained in a single folder. This folder often contains multiple files, such as app.json and launch.json files, perhaps an image file representing the extension's logo, various folders for source; "\src", other resources; "\res", and a test folder; "\test" folder. The extension does not need to follow a flat structure, which means that, depending on the amount of application files, additional folders can be used in the "src" or "test" folders to group objects based on their functionality, which can help make maintaining a large .al project easier.

File naming

Each file name must start with the corresponding type and ID, followed by a dot for full objects or a dash for extensions. The name of the object is written only with characters [A-Za-z0-9] and dot al is used for the file type.

File naming notation

Follow the syntax for file naming as shown below:

Full objects Extensions
<Type><Id>.<ObjectName>.al <Type><BaseId>-Ext<ObjectId>.<ObjectName>.al

Type map

Use the listed abbreviations for each type of object in the file naming:

Object Abbreviation
Page Pag
Page Extension PagExt
Page Customization PagCust
Codeunit Cod
Table Tab
Table Extension TabExt
XML Port Xml
Report Rep
Query Que
Enum Enu
Enum Extension EnuExt
Control Add-ins ConAddin

Examples of file naming

The following table illustrates how the file naming should look.

Object name File name
codeunit 1000 "Job Calculate WIP"
page 21 "Customer Card"
page 1234 "MyPag" extends "Customer Card"


We recommend keeping your AL code properly formatted as follows:

  • Use all lowercase letters for reserved language keywords. Built-in methods and types are not included in this rule because they are written using Pascal case.
  • Use four spaces for indentation.
  • Curly brackets are always on a new line. If there is one property, put it on a single line.

The following example illustrates these formatting rules.

page 123 PageName
                trigger OnAction()

        TempCustomer: Record Customer temporary;

    [EventSubscriber(ObjectType::Page, Page::"Item Card", 'OnAfterGetCurrRecordEvent', '', false, false)]
    local procedure OnOpenItemCard(var rec: Record Item)
        OnRecord: Option " ", Item, Contact;
        EnablePictureAnalyzerNotification(rec."No.", OnRecord::Item);

The AL Language extension offers users the option to automatically format their source code. For more information on how to use it, see AL Formatter.

Line length

In general, there is no restriction on line length, but lengthy lines can make the code unreadable. We recommend that you keep your code easily scannable and readable.

Object naming

Object names are prefixed. They start with the feature/group name, followed by the logical name as in these two examples:

  • Intrastat extension validation codeunit for Denmark
  • codeunit 123 "IntrastatDK Validation"


The "MS - " prefix is not required.

File structure

Inside an .al code file, the structure for all objects must follow the sequence below:

  1. Properties
  2. Object-specific constructs such as:
    • Table fields
    • Page layout
    • Actions
  3. Global variables
    • Labels (old Text Constants)
    • Global variables
  4. Methods


In AL, objects are referenced by their object name, not by their ID.


Page.RunModal(Page::"Customer Card", ...)
    Customer: Record Customer;

Variable naming

For variables they must:

  • Be named using PascalCase.
  • Have the Temp prefix if they are temporary variables.
  • Include the object name in the name (for objects).


TempCustomer: Record Customer temporary;
Vendor: Record Vendor; 

Method declaration

To declare a method, follow the guidelines below:

  • Include a space after a semicolon when declaring multiple arguments.
  • Semicolons can be used at the end of the signature/method header. If you use a snippet, the semicolons are not automatically added.
  • Methods are named as variables using Pascal case. However, this is not a mandatory rule.
  • There must be a blank line between method declarations. If you format your code using the AL Formatter tool, the auto-formatter sets the blank line between procedures.


local procedure MyProcedure(Customer: Record Customer; Int: Integer)

// space

local procedure MyProcedure2(Customer: Record Customer; Int: Integer)

Calling methods

When calling a method, include one space after each command if you are passing multiple parameters. Parentheses must be specified when you are making a method call or system call such as: Init(), Modify(), Insert() etc.


MyProcedure(1, 2); 

Type definition (colon)

When declaring a variable or a parameter, the name of that variable or parameter must be immediately followed by a colon, then a single space, and then the type of the variable/parameter as illustrated in the example below.

    Number: Integer;

local procedure MyProcedure(a: Integer; b: Integer): Integer 

See Also

Checklist for Submitting Your App
Rules and Guidelines for AL Code