Local scope in Luau: which route name does your code see?

Start with a question about visibility #

Imagine a fictional walking route with a general label, Harbor, and a temporary label, Tower, used while preparing one optional branch. Your task is to determine which label a particular line can read. Scope answers that question: it describes the region of code where a declared variable is available. It does not describe the distance between objects in the game world or how long a player stays on a route.

Read the example as plain Luau first. Write down each declaration and the block containing it, then trace the prints in execution order. These exercises only manipulate strings in memory. They do not rename a Roblox place, change a player's checkpoint, update a sign in Workspace, or save route data. Those operations require separate code and separate checks.

Follow a local variable into a child block #

The first example declares routeName before a do block. The block's print can read that outer variable because an inner block can access names declared in its enclosing scope. Inside the block, branchName is a new local. The two names refer to different variables, so printing them together does not replace the general route label. The final print still reads Harbor after the block finishes.

Predict the output before running: first Harbor and Tower on the same line, then Harbor. A tab separates the two arguments in the first print. Notice that branchName is not available as that local outside its block. If code later needs a result calculated inside, choose a deliberate return value or declare a suitable receiving variable outside; removing local is not a clear data-transfer design.

Open full-size image ↗

local routeName = "Harbor"
do
    local branchName = "Tower"
    print(routeName, branchName)
end
print(routeName)

A parent cannot read a child's local #

Visibility goes from an enclosing scope into a nested scope, not automatically back outward. Drawing a box around the do block makes this easier to see. branchName belongs inside that box. A later line beside the box has no access to that declaration. Naming a second, unrelated variable branchName elsewhere would create another variable rather than recover the original one.

When diagnosing an unexpected nil, examine where the declaration occurs before changing spelling everywhere. An unbound identifier in an ordinary standalone example can resolve as a missing global and produce nil; that does not expose the local that has already gone out of scope. Studio's analysis can also flag unknown names. Treat such a finding as a boundary problem to resolve, not proof that the expected string was deleted from storage.

Distinguish a new declaration from assignment #

The second example puts local routeName inside a child block. This declaration shadows the outer routeName: within that inner region, the same spelling selects a different variable containing Tower. Once the block ends, the outer variable is visible again and still contains Harbor. Shadowing can be intentional, but a beginner may accidentally use it when trying to update the outer value.

The next block uses routeName = "Market" without a new local declaration. At that line, the visible routeName is the outer local, so the assignment changes it. The final output is Market. Compare all three lines: Tower, Harbor, Market. The difference is the declaration, not the quotation marks or the use of a do block. Prefer distinct names when two values represent different concepts.

Open full-size image ↗

local routeName = "Harbor"
do
    local routeName = "Tower"
    print(routeName)
end
print(routeName)
do
    routeName = "Market"
end
print(routeName)

Check the position of a declaration #

A local becomes available after its declaration in the relevant scope. Do not assume that a local written later explains every earlier occurrence of the same spelling. Trace from the top of the block, identifying the declaration that is visible at each use. This approach also helps when a function contains several short blocks and a familiar name appears more than once.

For an exercise, put an outer label beside a nested block and annotate each print with the variable it should read. Keep the executable examples unchanged for the first run, then make one controlled change. Moving declarations, renaming variables, and changing values simultaneously makes it hard to identify the cause of new output. Record the prediction separately from the actual result.

Functions create another boundary #

A function's parameters and its own locals belong to that function's scope. A caller does not obtain those local names just because it called the function. When the caller needs a calculated label, have the function return it and assign that result to a named local at the call site. A nested function can use accessible outer locals, so moving it to another location may change what it can read.

Keep the distinction between visibility and communication explicit. A function that prints a label has produced output; it has not necessarily returned a value to its caller. A function that returns a string still has not updated a Roblox UI by itself. Review each boundary separately: which inputs are available, which result is returned, and which caller will apply that result.

Global does not mean every Roblox script #

An assignment to a name with no visible local can create or modify a global in the current execution environment. That broadens access within that environment and makes accidental name collisions harder to track. It does not establish a dependable shared variable across separate Roblox scripts, clients, and the server. Scope alone is not a networking or persistence mechanism.

Use explicit locals as your starting habit. If two scripts must share a definition, investigate a deliberate module interface; if a client and server must communicate, investigate the appropriate communication mechanism and validation. Those are different topics from this exercise. Do not replace a missing local with a global and conclude that multiplayer synchronization or saved progress has been fixed.

Make a small evidence-based handoff #

For a useful handoff, include the unchanged sample, its expected output, and the actual output from the run. Mark the inner declaration as a new variable and the later assignment as an update to the visible outer variable. Add a negative check showing that the child-only name is unavailable outside its block. Our standalone assertions cover these boundaries without touching any existing Roblox game.

Before applying the pattern to a real script, identify the exact variable and every block that uses it. Explain whether a change should stay temporary, update an outer value, or leave a function as a returned result. Run an appropriate test in a separate development copy and record what you observed. A successful string example proves its local behavior; it does not prove the entire game's route logic.