9.5 Variable Scoping, Declaration Placement & Object Lifetime

9.5 Variable Scoping, Declaration Placement & Object Lifetime

Quick Answer: The Microsoft skills outline lists "Implement variable scoping" as its own objective under Develop object-oriented code, and the exam tests it as a compiler question, not a style question. Three rules carry most of the marks. First, declarations are statements: since the current X++ compiler you may declare a variable anywhere a statement is legal, including inside a for initializer and inside a using statement, and the variable's lifetime is exactly the block it was declared in. Second, shadowing is illegal — re-declaring a name that already exists in the same or an enclosing scope is a hard compile error, unlike C# where an inner block may quietly hide an outer name. Third, instance variables declared in the class declaration are visible to every method of the class and of its subclasses, while a variable declared in a method is invisible everywhere else — which is why static methods cannot touch instance state and why an extension class's own fields are private to that extension.

---

1. The Three Scope Levels in X++

Scope answers one question: from which lines of code is this identifier reachable? X++ recognises three levels.

class ScopeExample
{
    // Instance variable: reachable from every method below and from subclasses.
    int a;

    void aNewMethod()
    {
        // Local variable: reachable only inside aNewMethod.
        int b;
    }
}

The distinction matters at compile time. A static method has no object instance, so it cannot read a at all. A subclass method can read a if a is protected or public, which is the reason base-class state is almost always declared protected rather than private in extensible frameworks.

---

2. Declare Anywhere: Declarations Are Statements

Legacy X++ forced every declaration to the top of the method, above the first executable statement. That restriction is gone. A declaration is now syntactically a declaration statement, so it may appear wherever a statement may appear. The practical payoff is precise scope control — you declare a variable immediately before the line that needs it, and the compiler guarantees nobody downstream can reuse it.

void MyMethod()
{
    for (int i = 0; i < 10; i++)
    {
        info(strFmt("i is %1", i));
    }
}

The counter i is scoped to the for statement itself, which includes the condition expression and the update expression. The moment the loop ends, i ceases to exist:

void MyMethod()
{
    for (int i = 0; i < 10; i++)
    {
        if (i == 7)
        {
            break;
        }
    }

    // Compiler error: "'i' isn't declared."
    info(strFmt("Found: %1", i));
}

Candidates who learned the old rule read that second snippet as valid and pick the wrong option. The fix in real code is deliberate: if the value must outlive the loop, hoist the declaration one level up so the enclosing block owns it.

Scopes can also be opened by a using statement, which is the idiomatic way to handle any .NET object implementing IDisposable:

static void AnotherMethod()
{
    str textFromFile;

    using (System.IO.StreamReader sr = new System.IO.StreamReader("c:\\test.txt"))
    {
        textFromFile = sr.ReadToEnd();
    }
    // sr is out of scope here, and Dispose() has already run — even if ReadToEnd threw.
}

The compiler translates using into a try block with an explicit Dispose call in finally, so the object is released deterministically rather than waiting on garbage collection.

---

3. Shadowing Is a Compile Error, Not a Warning

This is the single most frequently mis-answered scoping item, because developers arriving from C# or Java expect an inner declaration to shadow an outer one.

{
    int i;
    {
        int i;   // COMPILER ERROR
    }
}

The compiler reports: "A local variable named 'i' can't be declared in this scope because it would give a different meaning to 'i', which is already used in a parent or current scope to denote something else." The rule covers both an enclosing scope and the current scope, so neither nesting nor sequence rescues the second declaration. Rename one of them.

The same protection does not extend across the instance/local boundary: a local variable in a method may legitimately carry the same name as an instance variable, and inside that method the local wins. That asymmetry is a favourite distractor — the exam pairs a nested-block example (error) with a member-versus-local example (legal) and asks which compiles.

---

4. var: Implicit Typing Without Losing Strong Typing

var lets the compiler infer a variable's type from its initialiser. The variable remains strongly typed to exactly one unambiguous type; nothing becomes dynamic.

var var1 = "This is clearly a string.";      // str
var var2 = 27;                               // int, not real
var i    = System.Convert::ToInt32(3.4);     // System.Int32

The one hard rule: var is legal only on a declaration that supplies an initialisation expression. var x; cannot compile, because there is nothing to infer from.

Microsoft's own guidance recommends var in four situations:

• The type is obvious from the right-hand side of the assignment.
• The exact type is not important to the reader.
• For for loop counters.
• For disposable objects inside using statements.

And recommends against it whenever the initialiser does not make the type clear — for example, var x = myObject.ResultSoFar(); should be written int x = myObject.ResultSoFar(); so a maintainer does not have to open another class to learn the type.

---

5. Constants, readonly, and Why Macros Lose

Scope is precisely what separates a constant from a macro, and the exam frames this as a design-quality question.

class ConstantExample
{
    public const str MyContent = 'SomeValue';
}

str value = ConstantExample::MyContent;   // Double-colon syntax from outside the class.

Inside the declaring class the prefix is optional, which makes a class of public const members an effective, scoped replacement for a legacy macro library.

readonly differs from const in exactly one respect: a read-only field may be assigned once, either inline at the declaration or in the constructor, and never again. Use const for values known at compile time and readonly for values that depend on constructor arguments.

One legacy wrinkle is still worth knowing. A macro defined in a class declaration is effectively available in every method of every derived class. That behaviour began life as a defect in the legacy compiler, enough application code depends on it that the current compiler still honours it, and Microsoft explicitly advises against writing new code that relies on it — partly because it measurably slows compilation. The sanctioned middle path pins the macro value into a scoped constant:

private const int RetryNum = #OCCRetryCount#RetryNum;

---

6. X++ Has No null for Primitives

Scope decides where a variable is reachable; the type system decides what it holds before you assign anything. In X++ a declaration both allocates memory and initialises the variable to its type's default. Primitives never hold null.

Only container values, class references, and table buffers can be null in the traditional database sense — and a table buffer counts as null when every one of its fields holds its own null value. This is why if (custTable) is idiomatic X++ for "did the select find a row?" and why a mandatory int field cannot accept 0 during validateField.

---

7. Scenario Walk-Through: Refactoring a Long Posting Method

Scenario Description

A partner inherits a 300-line postJournalBatch() method. Every variable is declared in one block at the top, including two table buffers, a Map, a StreamReader, and six counters. A defect report says that a retry path occasionally posts with amounts left over from the previous iteration, and the compiler now rejects a small addition the team tried to make.

Step-by-Step Remediation

1. Move each declaration next to first use. The two counters used only inside the validation loop move inside that loop; the compiler then guarantees that a later block cannot read a stale value. This alone eliminates the leftover-amount defect, because the carry-over variable no longer survives the iteration.
2. Scope the loop counters into the for statements. for (int lineNo = 1; lineNo <= total; lineNo++) removes two method-level names.
3. Wrap the StreamReader in using. The reader is disposed deterministically at the end of its block instead of lingering until garbage collection, which also removes the manual finally block the previous author wrote.
4. Diagnose the new compiler error. The team's addition declared int lineNo; inside a nested validation block while lineNo already existed in the enclosing for. X++ treats that as shadowing and refuses to compile. Renaming the inner variable to validationLineNo resolves it.
5. Promote the two genuinely shared values. The posting profile and the ledger dimension set are read by four methods, so they become protected instance variables in the class declaration rather than parameters threaded through every call.
6. Replace the macro library with constants. The #PostingLimits macro block becomes private const members on the class, restoring IntelliSense, cross-references, and debugger visibility, and removing the compile-time penalty of a class-declaration macro.

---

8. Real-World Exam Traps: Variable Scoping

[!WARNING] Exam Trap 1: Reading a Loop Counter After the Loop A code sample breaks out of a for loop at a matching record and then prints the counter. If the counter was declared in the for initializer, this is a compile error, not a logic bug. Check where the declaration sits before judging the output.

[!WARNING] Exam Trap 2: Assuming Inner Blocks May Shadow Outer Names C# habits say the inner int i hides the outer one. X++ says no, and the error text explicitly mentions "a parent or current scope." Any option claiming the inner declaration merely hides the outer value is wrong.

[!WARNING] Exam Trap 3: var Without an Initialiser var counter; never compiles. If an option declares a var on one line and assigns it on the next, reject it regardless of how sensible the surrounding logic looks.

[!WARNING] Exam Trap 4: Expecting a Primitive to Be null A validation routine that tests if (amount == null) is not valid X++ thinking. A real defaults to 0.0 and can never be null; the correct test is against the type's documented null value, or if (!amount).

[!WARNING] Exam Trap 5: Reaching Instance State from a Static Method A static construct() or main() method has no instance, so it cannot read a variable declared in the class declaration. The fix is to instantiate the class and call an instance method, not to widen the variable's access modifier.