How much AL should you fit on a single line?

Normally I stay away from style and formatting discussions, but a piece of code came across my desk today that got me thinking about linebreaks, and when to use them AL, check out the video:

https://youtu.be/mJBvBGHMP3U

In this video, Erik explores a question that every AL developer encounters: how much code should you fit on a single line? Starting from the extreme case of an entire program on one line, he walks through proper formatting conventions, the history behind them, and why readability should always be your top priority.

The One-Liner: It Compiles, But Should You?

Erik begins with a provocative demonstration: the entire Hello World page extension written on a single line of code. Everything — the object declaration, triggers, variables, begin/end blocks — all crammed together with no line breaks.

And here’s the thing: it compiles just fine. Line breaks in AL (and in Pascal before it) are optional. The compiler doesn’t care about your whitespace.

But just because something is optional doesn’t mean you should skip it. You could enable word wrapping in VS Code and call it a day, but that doesn’t actually solve the readability problem.

Proper Formatting Conventions

Over the decades, the Pascal and AL communities have developed a shared understanding of where line breaks belong. Here’s how code should be structured:

  • Object declarations — the first line is just the identifier (e.g., pageextension 50100 CustomerListExt extends "Customer List")
  • Curly brackets — the JSON-inspired section delimiters in AL go on their own lines, with nothing else sharing the line
  • Triggers, procedures, and functions — the declaration goes on its own line
  • Variable sections — var gets its own line, and each variable declaration gets its own line
  • Begin/end blocks — properly indented with clear visual structure

The “If-Then-Exit” Trap

One pattern Erik sees far too often is cramming an if statement onto a single line:

if something then exit;

Some developers seem to think that exit is a special case that deserves one-line treatment. It’s not. The statement inside an if should always go on the next line, indented. This convention goes all the way back — even in Erik’s 1982 copy of Elementary Pascal (where Sherlock Holmes and Watson solve crimes using Pascal!), the body of an if statement is always on a separate, indented line.

Notably, the AL formatter does not automatically fix this particular case — it will leave if true then exit; on one line. But you still shouldn’t do it.

Where Does “Begin” Go?

When you have multiple statements inside an if, you need a begin...end block. The question is: where does begin go?

In C-like languages, there’s an eternal debate about brace placement. But in Pascal and AL, the convention has been clear for over 40 years: begin goes on the same line as then.

if true then begin
    message('yes!');
    message('no!');
end;

If you try to put begin on its own line, the AL formatter will move it right back. This is one of the many reasons not to turn off the formatter.

Breaking Long Boolean Expressions

Another common readability challenge is long conditional expressions. When you have multiple conditions chained together, the line quickly becomes unreadable:

if true and false and true and (false and false) or true and true then

A much better approach is to break the boolean expression across multiple lines. The formatter supports this:

if true and
   false and
   true and
   (false and false) or
   true and
   true then
    Message('!!');

This convention traces back to the days when screens had a fixed number of characters and horizontal scrolling was either unsupported or painfully slow. Even today, long lines hurt readability.

Don’t Hide Control Flow

Erik highlights another anti-pattern: hiding control flow structures like repeat...until on the same line as a then:

if true then repeat Clear(Customer); until Vendor.Next() = 0;

A repeat hidden behind an if statement is what Erik calls “a mental trap.” Each control flow structure deserves its own properly indented block so that the logic is immediately visible when someone glances at the code.

The Complete Example

Here’s the properly formatted source code that Erik builds up throughout the video:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage()
    var
        Customer: Record Customer;
        Vendor: Record Vendor;
    begin
        if true then begin
            message('yes!');
            message('no!');
        end;

        if true and
           false and
           true and
           (false and false) or
           true and
           true then
            Message('!!');

        if true then
            exit;
        if false then
            exit;

    end;
}

Key Takeaways

  1. Don’t turn off the AL formatter. Erik won’t even show you how — it’s a setting in VS Code, and you should leave it alone.
  2. An if statement should never be a single line. The body always goes on the next line, indented. At minimum, an if statement is two lines.
  3. begin goes on the same line as then — this has been the convention for over 40 years.
  4. Break long boolean expressions across multiple lines to keep things readable.
  5. Don’t hide control flow. Structures like repeat...until should never be tucked away on the same line as another statement.
  6. Readability over rigid rules. Erik isn’t a strong believer in very rigid style guides, but he is a strong believer in readability. If it takes someone 10 minutes to understand a piece of code that they could rewrite in 10 minutes, your formatting has failed.

The bottom line: write code that can be read and understood by others at a glance. Proper formatting isn’t about aesthetics — it’s about making the logic of your code immediately apparent to anyone who encounters it.

Picture of hougaard

hougaard