Naming pattern (LC0092)

Names of procedures, variables, parameters, return values, objects, fields, actions, enum values, and controls should follow consistent naming conventions. By default, this rule enforces Microsoft’s best practices and AL Guidelines naming conventions.

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:

Target	Default convention	Applies to
Procedure	Must start with an uppercase letter	All user-defined procedures
LocalProcedure	(inherits Procedure)	Local procedures
GlobalProcedure	(inherits Procedure)	Non-local, non-event procedures
EventSubscriber	(inherits Procedure)	Methods with `[EventSubscriber]`
EventDeclaration	(inherits Procedure)	Methods with `[IntegrationEvent]` or `[BusinessEvent]`
Variable	Must start with an uppercase letter, underscore followed by uppercase, or x followed by uppercase for xRec pattern (single-letter names are exempt); must not contain %, &, !, ?	Local and global variables
Parameter	Must start with an uppercase letter, underscore followed by uppercase, or x followed by uppercase for xRec pattern (single-letter names are exempt)	Procedure parameters
ReturnValue	Must start with an uppercase letter	Named return values
Object	Must start with an uppercase letter	Tables, pages, codeunits, reports, queries, XmlPorts, enums, interfaces, permission sets
Field	Must start with a letter (upper or lower); must not contain %, &, !, ?	Table fields
Action	Must start with an uppercase letter	Page actions
EnumValue	Must start with an uppercase letter	Enum values
Control	Must start with an uppercase letter	Page controls

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.

When the rule does not trigger

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

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. Sub-targets (LocalProcedure, GlobalProcedure, EventSubscriber, EventDeclaration) inherit from Procedure when not explicitly configured.

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.

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:

Tier	Example message	When used
1. Description	`should start with an uppercase letter. Consider: "MyProcedure"`	Built-in defaults, or user provides `AllowDescription`/`DisallowDescription`
2. Auto-suggestion	`must match pattern "^[A-Z]". Consider: "MyProcedure"`	Known pattern with auto-fix, but no description
3. Regex explained	`must start with uppercase letter A-Z`	Simple regex the rule can translate to English
4. Raw regex	`must match pattern "(?=^[A-Z])(?!.*_{2,})"`	Complex patterns that can’t be explained

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.