Do not use Object IDs as object references

A variable declared as Record 18 or a method call like Codeunit.Run(80) compiles, but the numeric ID is meaningless to anyone reading the code — they have to look up which object the number refers to. When the referenced object is renamed, a name-based reference like Record "Customer Ledger Entry" breaks at compile time, making every stale callsite easy to find. A numeric ID compiles silently, hiding the drift.

Use the object name instead of the numeric ID in variable declarations, property values, built-in method invocations, and event subscriber attributes.

Example

Variable declarations

codeunit 50100 "My Codeunit"
{
    var
        CustLedgEntry: Record 18; // Do not use Object IDs as object references [LC0003]
}

Use the object name instead:

codeunit 50100 "My Codeunit"
{
    var
        CustLedgEntry: Record "Customer Ledger Entry";
}

This applies to all data types that reference objects: Record, Codeunit, Page, Report, Xmlport, and Query.

Built-in method invocations

procedure PostSalesOrder()
begin
    Codeunit.Run(80); // Do not use Object IDs as object references [LC0003]
end;

Use the object name instead:

procedure PostSalesOrder()
begin
    Codeunit.Run(Codeunit::"Sales-Post");
end;

This also applies to Page.Run(), Page.RunModal(), Report.Run(), Report.RunModal(), Xmlport.Run(), Xmlport.Export(), Xmlport.Import(), Query.SaveAsCsv(), RecordRef.Open(), and similar methods.

EventSubscriber attributes

[EventSubscriber(ObjectType::Codeunit, 80, OnAfterPostSalesDoc, '', false, false)] // Do not use Object IDs as object references [LC0003]
local procedure OnAfterPostSalesDocSubscriber()
begin
end;

Use the object name instead:

[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", OnAfterPostSalesDoc, '', false, false)]
local procedure OnAfterPostSalesDocSubscriber()
begin
end;

Exception

Page.Run(0) and Page.RunModal(0) are valid — 0 is a sentinel that runs the default page for the record’s table. The diagnostic does not flag this pattern.