Use parenthesis for function calls (FC0003)

Function calls should always include parentheses, even when there are no arguments. This makes it visually clear that a procedure is being invoked rather than a variable being accessed.

A code fix is available for this diagnostic.

Example

The following code calls a function without parentheses:

codeunit 50100 MyCodeunit
{
    procedure MyProcedure()
    begin
        DoSomething; // Use parenthesis for function calls [FC0003]
    end;

    local procedure DoSomething()
    begin
    end;
}

To fix this, add parentheses to the function call:

codeunit 50100 MyCodeunit
{
    procedure MyProcedure()
    begin
        DoSomething();
    end;

    local procedure DoSomething()
    begin
    end;
}

Why this matters

While the AL compiler accepts both Record.Count and Record.Count(), these two forms are parsed as fundamentally different constructs. Without parentheses it looks like accessing a property; with parentheses it is clearly a method call.

Under the hood, the compiler produces a MemberAccessExpression for Record.Count and an InvocationExpression for Record.Count() — these are what analyzers receive, and they are two entirely different node types. Today the AL Language does not have properties on objects, so the compiler lets you get away with either form. But the distinction already affects static analysis tooling and if AL ever introduces real properties, Record.Count and Record.Count() could mean entirely different things.

By always including parentheses you make the intent unambiguous — both for tooling and for anyone reading your code.