Pragmatic use of pragmas in AL and Business Central

In AL you can use #pragma to tell the compiler that you’re way smarter than it. Check out the video:

In this video, Erik demonstrates how to use pragmas in AL for Business Central — a practical technique for selectively suppressing compiler warnings when you know your code is safe, without losing the benefit of those warnings elsewhere in your project.

What Are Pragmas?

If you’ve developed in languages like C or C++, you’re already familiar with the concept of a preprocessor — something that works on the source code before it’s fed into the compiler. AL has the same capability. Pragmas let you instruct the compiler on what to do (or not do) before it actually starts compiling. Think of it as a thin layer sitting on top of the compilation process.

One of the most useful things pragmas enable is the ability to suppress specific warnings that the compiler would normally raise — particularly when you, as the developer, know better than the compiler that a particular line of code is safe.

The Problem: False-Positive Warnings

Erik starts by creating a simple, pure function that takes a text value and replaces spaces with underscores:

procedure GetRidOfSpaces(input: Text): Text
begin
    exit(input.replace(' ', '_'));
end;

This is a nice, clean function — it takes any text value and returns a text of the same length or shorter (since it’s only doing character replacement). It will never return a string larger than the one it received.

Now, when you use this function and assign the result back to a field with a defined length:

Rec.Name := GetRidOfSpaces(Rec.Name);

The compiler raises warning AA0139: “Possible overflow assigning text to text[100].” The compiler sees that GetRidOfSpaces returns an unbounded Text type, and Rec.Name is a Text[100]. It worries about a potential runtime error.

But we know better. We’re passing Rec.Name (which is already 100 characters or fewer) into a function that only replaces characters — it can never make the string larger. This warning is a false positive in this specific context.

The Solution: Pragma Warning Disable/Restore

Rather than turning off warning AA0139 for the entire project (which would be reckless), you can surgically disable it for just the line where you know it’s safe:

#pragma warning disable AA0139
        Rec.Name := GetRidOfSpaces(Rec.Name);
#pragma warning restore

The #pragma warning disable directive tells the compiler to stop reporting a specific warning code. The #pragma warning restore directive re-enables it immediately after. This means subsequent lines will still get checked:

        Rec.Name := GetRidOfSpaces(Rec.Address);

This second line would still trigger the warning (if Address has a different length than Name), because the pragma restore has already re-enabled the check. That’s exactly the behavior you want — precision control over which lines are suppressed.

Handling Multiple Warnings

Erik also demonstrates suppressing another warning: AA0215, which flags naming conventions. The same pattern applies:

#pragma warning disable AA0215
pageextension 50100 CustomerListExt extends "Customer List"
#pragma warning restore

You can use this pattern for any warning code that the AL compiler or code analyzers produce.

Complete Example

Here’s the full source file showing both pragmas in action:

#pragma warning disable AA0215
pageextension 50100 CustomerListExt extends "Customer List"
#pragma warning restore
{
    trigger OnOpenPage();
    begin
#pragma warning disable AA0139
        Rec.Name := GetRidOfSpaces(Rec.Name);
#pragma warning restore
        Rec.Name := GetRidOfSpaces(Rec.Address);
    end;

    procedure GetRidOfSpaces(input: Text): Text
    begin
        exit(input.replace(' ', '_'));
    end;
}

Key Things to Notice

  • The pragma lines are not part of the source code per se — they are instructions to the compiler on how to consume the source code. They can appear anywhere and don’t need to align with the logical structure of your code.
  • Always use #pragma warning restore after your targeted line(s). If you place disable at the top of a file without a corresponding restore, you’ll suppress the warning for the entire file — defeating the purpose.
  • Each pragma targets a specific warning code (like AA0139 or AA0215), so you never accidentally suppress unrelated warnings.

Scope: Where to Place Pragmas

You have flexibility in where you place the disable directive:

  1. Around a single line (recommended) — Disable just before the line, restore just after. This is the most precise and safest approach.
  2. At the top of a file — Disables the warning for the entire file. Use sparingly and only when you’re confident the warning is irrelevant throughout.

Erik strongly recommends the first approach: be as targeted as possible so you continue to benefit from the compiler’s analysis everywhere else.

A Note on Other Preprocessor Directives

Erik briefly mentions that AL also supports other preprocessor directives starting with #, such as conditional compilation flags. These let you do things like include different source code for on-premises vs. AppSource builds. However, those involve additional considerations around build pipelines and configuration, which is a topic for another day.

Summary

Pragmas in AL give you fine-grained control over compiler warnings. The key takeaway is to be pragmatic about it: keep your code analyzers turned on, strive for zero warnings, but when you genuinely know that a specific line is safe and the compiler simply can’t infer that, use #pragma warning disable and #pragma warning restore to silence that one warning on that one line. You stay in control, your code stays clean, and the compiler continues to protect you everywhere else.

Picture of hougaard

hougaard