LinterCop on ALCops

Do not use Object IDs as object references (LC0003)

Mon, 01 Jan 0001 00:00:00 +0000

When referencing objects in variable declarations, property values, built-in method invocations, or event subscriber attributes, use the object name instead of a numeric Object ID. Numeric IDs are not readable and cannot be safely renamed.

A code fix is available for this diagnostic.

Examples

Variable declarations

Using a numeric ID to reference an object in a variable declaration:

codeunit 50100 MyCodeunit
{
 var
 MyTable: Record 50100;
}

Use the object name instead:

Maintainability Index metric (LC0007)

Mon, 01 Jan 0001 00:00:00 +0000

This rule reports the calculated Maintainability Index for every procedure and trigger, allowing developers to identify areas that may benefit from refactoring. The companion rule LC0008 triggers a warning when the index falls below a configurable threshold.

What is the Maintainability Index?

The Maintainability Index (MI) is a composite software metric that quantifies how easy a piece of code is to understand, modify, and maintain. It condenses several lower-level measurements into a single score on a 0–100 scale, where higher values indicate more maintainable code.

Maintainability Index threshold exceeded (LC0008)

Mon, 01 Jan 0001 00:00:00 +0000

This rule triggers when a procedure’s Maintainability Index falls at or below a configurable threshold. A low Maintainability Index indicates code that is likely difficult to understand, test, and maintain — and disproportionately expensive to change safely.

What triggers this diagnostic?

The analyzer calculates the Maintainability Index for every procedure and trigger in your AL project. When the calculated score is at or below the configured threshold, this diagnostic is reported on the procedure.

Cyclomatic Complexity metric (LC0009)

Mon, 01 Jan 0001 00:00:00 +0000

This rule reports the calculated Cyclomatic Complexity for every procedure and trigger, allowing developers to identify overly complex code. The companion rule LC0010 triggers a warning when the complexity meets or exceeds a configurable threshold.

What is Cyclomatic Complexity?

Cyclomatic Complexity is a software metric that quantifies the number of linearly independent paths through a section of source code. It was introduced by Thomas J. McCabe Sr. in 1976 and has since become one of the most widely adopted complexity metrics in the software industry.

Cyclomatic Complexity threshold exceeded (LC0010)

Mon, 01 Jan 0001 00:00:00 +0000

This rule triggers when a procedure’s Cyclomatic Complexity meets or exceeds a configurable threshold. High complexity means more independent execution paths, making the code harder to understand, test exhaustively, and maintain safely.

What triggers this diagnostic?

The analyzer calculates the Cyclomatic Complexity for every procedure and trigger in your AL project. When the calculated score is greater than or equal to the configured threshold, this diagnostic is reported on the procedure.

DataClassification redundancy (LC0019)

Mon, 01 Jan 0001 00:00:00 +0000

The DataClassification property set on a table automatically applies to all its fields. When individual fields repeat the same value that is already defined at the table level, the declaration is redundant.

Redundant property declarations clutter the code with repeated lines that carry no additional meaning. They also increase the maintenance burden: if the table-level classification changes, every field that duplicates the old value must be updated individually. Over time this creates a risk that field-level values drift out of sync with the intended table-level default.

ApplicationArea redundancy (LC0020)

Mon, 01 Jan 0001 00:00:00 +0000

The ApplicationArea property set on a page automatically applies to all its controls. When individual controls repeat the same value that is already defined at the page level, the declaration is redundant.

Redundant property declarations clutter the code with repeated lines that carry no additional meaning. They also increase the maintenance burden: if the page-level application area changes, every control that duplicates the old value must be updated individually. Over time this creates a risk that control-level values drift out of sync with the intended page-level default.

Event subscriber arguments should use identifier syntax (LC0028)

Mon, 01 Jan 0001 00:00:00 +0000

Since Business Central 2023 wave 1 (BC22), event subscriber arguments support identifier syntax instead of string literals. Using identifiers unlocks powerful Visual Studio Code navigation features such as Go To Definition, Go To References, tooltips, and CodeLens reference counts.

This rule reports a diagnostic when event subscriber attribute parameters still use the old string literal syntax (single quotes) instead of the new identifier syntax.

Why this matters

When event subscriber arguments use string literals, the AL Language extension cannot resolve the reference. This means no navigability — you can’t jump to the event publisher, see who else subscribes, or get tooltips.

Use ReadIsolation instead of LockTable (LC0031)

Mon, 01 Jan 0001 00:00:00 +0000

This rule flags calls to LockTable() and suggests replacing them with ReadIsolation := IsolationLevel::UpdLock.

While the change in code is small, the difference at the platform level is significant. LockTable() modifies the global session state: once called on any record variable, every subsequent read against that table — on any variable instance — will acquire an update lock for the remainder of the transaction. This means an event subscriber, a FlowField calculation, or unrelated code further down the call stack can end up locking rows it never intended to touch.

App manifest runtime behind (LC0033)

Mon, 01 Jan 0001 00:00:00 +0000

The runtime version specified in app.json should be kept up to date with the target Business Central version. Using an outdated runtime version may prevent you from using newer AL language features and APIs.

Example

If your app.json specifies an old runtime:

{
 "runtime": "10.0"
}

And you’re targeting a newer Business Central version, update the runtime to match:

{
 "runtime": "14.0"
}

Explicitly set RunTrigger (LC0040)

Mon, 01 Jan 0001 00:00:00 +0000

When calling Insert, Modify, or Delete on a record, the RunTrigger parameter should be explicitly specified. Relying on the default value makes the code’s intent unclear and can lead to unexpected behavior.

Example

The following code uses Insert without specifying RunTrigger:

codeunit 50100 MyCodeunit
{
 procedure CreateRecord()
 var
 MyRecord: Record MyTable;
 begin
 MyRecord.Init();
 MyRecord.Insert(); // Explicitly set RunTrigger [LC0040]
 end;
}

To fix this, explicitly specify the RunTrigger parameter:

Use SecretText for sensitive text (LC0043)

Mon, 01 Jan 0001 00:00:00 +0000

Sensitive data such as passwords, API keys, and tokens should be stored in SecretText variables rather than plain Text variables. SecretText provides additional protection by preventing the value from being logged or displayed accidentally.

Example

The following code stores a sensitive value in a plain Text variable:

codeunit 50100 MyCodeunit
{
 procedure Authenticate()
 var
 ApiKey: Text; // Use SecretText for sensitive text [LC0043]
 begin
 ApiKey := GetApiKey();
 end;
}

To fix this, use SecretText for sensitive values:

Error invocation using text constant (LC0048)

Mon, 01 Jan 0001 00:00:00 +0000

When calling Error() with a message, use a Label variable instead of a text constant. Labels support localization and provide better consistency across the codebase.

Example

The following code uses a text constant in Error:

codeunit 50100 MyCodeunit
{
 procedure ValidateAmount(Amount: Decimal)
 begin
 if Amount < 0 then
 Error('Amount cannot be negative'); // Error invocation using text constant [LC0048]
 end;
}

To fix this, use a Label variable:

codeunit 50100 MyCodeunit
{
 var
 AmountCannotBeNegativeErr: Label 'Amount cannot be negative';

 procedure ValidateAmount(Amount: Decimal)
 begin
 if Amount < 0 then
 Error(AmountCannotBeNegativeErr);
 end;
}

Internal procedure not referenced (LC0052)

Mon, 01 Jan 0001 00:00:00 +0000

An internal procedure that is never called from within the extension is dead code and should be removed. Unused internal procedures add maintenance burden and code noise.

Example

The following internal procedure is never referenced:

codeunit 50100 MyCodeunit
{
 internal procedure UnusedHelper() // Internal procedure not referenced [LC0052]
 begin
 end;

 procedure DoWork()
 begin
 // UnusedHelper is never called
 end;
}

To fix this, either use the procedure or remove it:

Internal procedure only used in current object (LC0053)

Mon, 01 Jan 0001 00:00:00 +0000

When an internal procedure is only called from within the same object, it should be declared as local instead. This reduces the procedure’s visibility to the minimum required scope.

Example

The following internal procedure is only used within the same codeunit:

codeunit 50100 MyCodeunit
{
 internal procedure Helper() // Internal procedure only used in current object [LC0053]
 begin
 end;

 procedure DoWork()
 begin
 Helper();
 end;
}

To fix this, change the procedure to local:

Interface object name guide (LC0054)

Mon, 01 Jan 0001 00:00:00 +0000

Interface objects should follow naming conventions that clearly identify them as interfaces. This typically means using a prefix like “I” or a suffix that indicates the interface nature.

Consistent naming makes it easier to identify interfaces at a glance and improves code readability.

Example

The following interface doesn’t follow naming conventions:

interface PaymentProcessor // Interface object name guide [LC0054]
{
}

To fix this, use a consistent naming convention:

interface IPaymentProcessor
{
}

API page canonical field name guide (LC0063)

Mon, 01 Jan 0001 00:00:00 +0000

API pages should use canonical field names that follow standard naming conventions for OData/REST APIs. This ensures consistency and improves discoverability for API consumers.

Example

The following API page uses non-canonical field names:

page 50100 "My API Page"
{
 PageType = API;
 EntityName = 'customer';
 EntitySetName = 'customers';

 layout
 {
 area(Content)
 {
 field(Customer_Name; Rec.Name) // API page canonical field name guide [LC0063]
 {
 }
 }
 }
}

To fix this, use canonical field names:

Use IsEmpty method instead of Count (LC0081)

Mon, 01 Jan 0001 00:00:00 +0000

When checking if a recordset has any records, use IsEmpty instead of comparing Count to zero. The IsEmpty method is more efficient because it stops after finding the first record, while Count must enumerate all records.

Example

The following code inefficiently uses Count to check for records:

codeunit 50100 MyCodeunit
{
 procedure HasCustomers(): Boolean
 var
 Customer: Record Customer;
 begin
 exit(Customer.Count() > 0); // Use IsEmpty method instead of Count [LC0081]
 end;
}

To fix this, use IsEmpty:

Use Query or Find with Next instead of Count (LC0082)

Mon, 01 Jan 0001 00:00:00 +0000

When you need to get the count of records that match complex criteria, consider using a Query object or iterating with FindSet/Next. In some scenarios, this can be more efficient than using Count, especially when filters are complex or when you need to process the records anyway.

Use built-in date/time methods (LC0083)

Mon, 01 Jan 0001 00:00:00 +0000

Business Central provides built-in methods for common date and time operations. Use these methods instead of manually calculating dates or times, as they handle edge cases like leap years and month boundaries correctly.

A code fix is available for this diagnostic.

Example

The following code manually calculates the first day of the month:

codeunit 50100 MyCodeunit
{
 procedure GetFirstDayOfMonth(InputDate: Date): Date
 begin
 exit(DMY2Date(1, Date2DMY(InputDate, 2), Date2DMY(InputDate, 3))); // Use built-in date/time methods [LC0083]
 end;
}

To fix this, use the built-in method:

Page style should not use string literal (LC0086)

Mon, 01 Jan 0001 00:00:00 +0000

When setting the Style property on page fields, use the Style enum values instead of string literals. Using enums provides compile-time validation and prevents typos.

Example

The following code uses a string literal for Style:

page 50100 MyPage
{
 layout
 {
 area(Content)
 {
 field(Amount; Rec.Amount)
 {
 Style = 'Strong'; // Page style should not use string literal [LC0086]
 }
 }
 }
}

To fix this, use the Style enum:

Option type should be Enum (LC0088)

Mon, 01 Jan 0001 00:00:00 +0000

The Option data type is a legacy construct. For new development, use Enum types instead. Enums are extensible, provide better IntelliSense support, and allow for cleaner code patterns.

Example

The following field uses an Option type:

table 50100 MyTable
{
 fields
 {
 field(1; Status; Option) // Option type should be Enum [LC0088]
 {
 OptionMembers = Open,Closed,Pending;
 }
 }
}

To fix this, create an Enum and use it instead:

Cognitive Complexity metric (LC0089)

Mon, 01 Jan 0001 00:00:00 +0000

Cognitive Complexity measures how difficult code is to understand, as opposed to how difficult it is to execute (Cyclomatic Complexity). It takes into account nesting depth, break in linear flow, and structural complexity.

This rule reports the calculated Cognitive Complexity for procedures, allowing developers to identify code that may be hard to understand and maintain.

Cognitive Complexity threshold exceeded (LC0090)

Mon, 01 Jan 0001 00:00:00 +0000

This rule triggers when a procedure’s Cognitive Complexity exceeds a configurable threshold. High cognitive complexity indicates code that is difficult to understand and reason about.

Consider refactoring complex procedures by:

Extracting nested logic into well-named helper methods
Using early returns to reduce nesting
Simplifying conditional logic
Breaking down complex procedures into smaller, focused units

AllowInCustomizations redundancy (LC0094)

Mon, 01 Jan 0001 00:00:00 +0000

When a table or tableextension defines AllowInCustomizations at the object level, individual fields do not need to repeat the same value. Redundant AllowInCustomizations properties on fields add noise without providing additional value.

A code fix is available for this diagnostic.

Example

The following field redundantly specifies the same AllowInCustomizations as the table:

table 50100 MyTable
{
 AllowInCustomizations = Never;

 fields
 {
 field(1; MyField; Integer)
 {
 AllowInCustomizations = Never;
 }
 }
}

To fix this, remove the redundant property from the field:

LinterCop on ALCops

Do not use Object IDs as object references (LC0003)

Examples

Variable declarations

Maintainability Index metric (LC0007)

What is the Maintainability Index?

Maintainability Index threshold exceeded (LC0008)

What triggers this diagnostic?

Cyclomatic Complexity metric (LC0009)

What is Cyclomatic Complexity?

Cyclomatic Complexity threshold exceeded (LC0010)

What triggers this diagnostic?

DataClassification redundancy (LC0019)

ApplicationArea redundancy (LC0020)

Event subscriber arguments should use identifier syntax (LC0028)

Why this matters

Use ReadIsolation instead of LockTable (LC0031)

App manifest runtime behind (LC0033)

Example

Explicitly set RunTrigger (LC0040)

Example

Use SecretText for sensitive text (LC0043)

Example

Error invocation using text constant (LC0048)

Example

Internal procedure not referenced (LC0052)

Example

Internal procedure only used in current object (LC0053)

Example

Interface object name guide (LC0054)

Example

API page canonical field name guide (LC0063)

Example

Use IsEmpty method instead of Count (LC0081)

Example

Use Query or Find with Next instead of Count (LC0082)

See also

Use built-in date/time methods (LC0083)

Example

Page style should not use string literal (LC0086)

Example

Option type should be Enum (LC0088)

Example

Cognitive Complexity metric (LC0089)

See also

Cognitive Complexity threshold exceeded (LC0090)

See also

AllowInCustomizations redundancy (LC0094)

Example