Name does not match naming convention

A procedure named myProcedure or a variable prefixed with % compiles without errors, but inconsistent naming makes symbol search unreliable and slows code review. By default, this rule enforces Microsoft’s best practices and AL Guidelines naming conventions. Override the defaults or add custom patterns per target in alcops.json.

Example

The following procedure name violates the default convention (must start with an uppercase letter):

codeunit 50100 MyCodeunit
{
    procedure myProcedure() // Procedure name "myProcedure" should start with an uppercase letter. Consider: "MyProcedure" [LC0092]
    begin
    end;
}

To fix this, use PascalCase:

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

Naming targets

The rule checks the following naming targets, each with a default convention:

These conventions are implemented as regex patterns under the hood (^[A-Z], ^[A-Za-z], [%&!?]). You can override them with custom patterns in alcops.json (see Configuration ).

AllowPattern: The name must match this regex. If it doesn’t, a warning is reported.

DisallowPattern: The name must not match this regex. If it does, a warning is reported.

Exception

• The symbol is obsolete
• The method is a trigger (platform-defined name)
• The method implements an interface (can’t change the name)
• Object names have AppSourceCop affixes stripped before checking
• Enum values are not checked by default (opt-in only)

Opting in to enum value checks

Enum value naming is not checked by default because enum values starting with digits (e.g., "1 Day", "30 Days") are common in AL and not prohibited by Microsoft guidelines. To enable enum value naming checks, configure it explicitly in alcops.json:

{
    "NamingPatterns": {
        "EnumValue": {
            "AllowPattern": "^[A-Z]",
            "AllowDescription": "should start with an uppercase letter"
        }
    }
}

Configuration

Override default patterns or add custom patterns in alcops.json:

{
    "NamingPatterns": {
        "Procedure": {
            "AllowPattern": "^[A-Z][A-Za-z0-9]*$",
            "AllowDescription": "should use strict PascalCase (letters and digits only)",
            "DisallowPattern": "_",
            "DisallowDescription": "should not contain underscores"
        },
        "Variable": {
            "DisallowPattern": "^[gl](rec|txt|int)",
            "DisallowDescription": "should not use Hungarian notation (e.g., grecCustomer, ltxtName)"
        }
    }
}

Only targets you specify are overridden. Unspecified targets keep the built-in defaults.

Inheritance follows these chains (from specific to general):

• LocalProcedure, GlobalProcedure, EventSubscriber, EventDeclaration -> Procedure
• LocalVariable, GlobalVariable -> Variable
• Parameter -> LocalVariable -> Variable
• VarParameter -> Parameter -> LocalVariable -> Variable
• ReturnValue -> LocalVariable -> Variable

When resolving patterns, the rule always uses the closest configured target in the chain (own override first, then parent overrides, then built-in defaults).

In the example above:

• Procedure enforces strict PascalCase (letters and digits only, no spaces or special characters) and disallows underscores in procedure names.
• Variable disallows Hungarian notation prefixes. The pattern catches common scope-type prefix combinations like grec (global record), lrec (local record), gtxt (global text), lint (local integer), etc.

You can also override sub-targets directly when you need different conventions, for example stricter rules for local variables or separate rules for var parameters:

{
    "NamingPatterns": {
        "LocalVariable": {
            "DisallowPattern": "^_",
            "DisallowDescription": "should not start with underscore"
        },
        "VarParameter": {
            "AllowPattern": "^Ref[A-Z]",
            "AllowDescription": "should start with Ref followed by PascalCase"
        }
    }
}

AllowDescription / DisallowDescription: Optional human-readable description shown in the diagnostic message instead of the raw regex pattern. Should start with “should” or “should not”. When omitted, the rule auto-generates a description for common patterns or falls back to showing the regex.

Diagnostic message tiers

The rule uses a four-tier strategy for diagnostic messages, from most to least user-friendly:

Object name affix stripping

When checking object names, AppSourceCop mandatory prefixes and suffixes are stripped before the pattern check. For example, if mandatoryPrefix is "CONTOSO" and the object is named CONTOSOMyTable, the rule checks MyTable against the pattern.

See also

• Best Practices for AL Code on Microsoft Learn
• AL Naming Conventions on AL Guidelines