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 has object names with only characters [A-Za-z0-9], object type, and dot al, for file type. In your extension, the name of each new application object (table, page, codeunit), must contain a prefix or suffix. This rule applies to all objects.

File naming notation

Follow the syntax for file naming as shown below:

Full objects Extensions
<ObjectNameSuffix>.<FullTypeName>.al <ObjectNameSuffix>.<FullTypeName>
<PrefixObjectName>.<FullTypeName>.al <PrefixObjectName>.<FullTypeName>

Type map

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

Object Abbreviation
Page Page
Page Extension PageExt
Page Customization PageCust
Codeunit Codeunit
Table Table
Table Extension TableExt
XML Port Xmlport
Report Report
Request Page RequestPage
Query Query
Enum Enum
Enum Extension EnumExt
Control Add-ins ControlAddin
Dotnet Dotnet
Profile Profile

Examples of object naming


table 70000000 MyPrefixSalesperson


page 70000000 MyPrefixSalesperson

Page extension



codeunit 70000000 MyPrefixSalesperson

File naming examples

For the listed objects above, these are examples of the file naming.

Object name File name
codeunit 70000000 MyPrefixSalesperson
page 70000000 MyPrefixSalesperson
page 70000000 MyPrefixSalesperson 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