Scope and shadowing

Every name you declare is visible to some parts of your program and invisible to the rest. Scope is the word for the region where a name works. It is not an advanced topic — you have been relying on it since your first function — but it is the topic that decides whether a program stays understandable as it grows.

The reason to care is not tidiness. If every name were visible everywhere, then every function could quietly interfere with every other, and understanding one line would mean reading the whole program. Scope is what lets you open one function and reason about it on its own.

A block is a pair of curly braces and everything between them. A function body is a block. The braces after an if are a block. So are the braces after an else, and a bare pair of braces on their own.

Names declared with let or const belong to the block they were declared in. When execution leaves that block, the name is gone — not hidden, gone. This is what block-scoped means, and it is why two different if branches can each declare a total without arguing.

A function's parameters follow the same rule: they belong to the function body and exist nowhere else. That is why the caller's variable and the parameter can share a name, or not share one, without anything being affected either way.

Code inside a block can read names declared outside it. A function can use a const declared above it at the top level of the file, without that value being passed in. This is why the worked examples in earlier lessons could mention things declared before them.

The reverse is not true. Nothing outside a block can see a name declared inside it. A function's local values are private to it, and that is the property the whole idea rests on: you can rename a local variable in one function without checking a single other line of the program.

Which outer names a piece of code can see is decided by where it is written in the source, not by who calls it. Two functions declared at the top level of a file can both see the file's top-level names, no matter which of them calls the other.

Picture each block as a room built inside a larger room. Every room has a window facing outwards, so from inside you can see everything in the room around you, and everything in the room around that.

The windows are one-way. Standing in the outer room, you cannot see into the rooms built inside it. And when a small room is demolished — when execution leaves the block — everything that was only in that room goes with it.

If you declare a name inside a block and that name already exists outside, the inner declaration wins inside that block. Every mention of the name in there refers to the inner one. This is called shadowing: the inner name casts a shadow over the outer one.

The crucial part is that shadowing does not modify the outer name. It hides it, temporarily and locally. When the block ends, the outer name is exactly as it was — same value, untouched. The second worked example below shows three values living under one name at three depths, each unaffected by the others.

Shadowing is not automatically a mistake. A short helper that uses total for its own running total is fine even if the file has a total elsewhere. It becomes a mistake when you shadow by accident and then wonder why the outer value never changed — which it never did, because you were writing to a different variable the whole time.

The opposite error is worse. Instead of declaring your own local name, you assign to one that lives outside the function. It works the first time, so it feels correct.

The trouble arrives on the second call. The function now starts from whatever the last call left behind, so the same arguments produce a different answer — and every other part of the program that reads that variable has silently had the rug pulled out from under it. Bugs of this kind are hard to find precisely because the broken function looks fine in isolation; the damage shows up somewhere else entirely.

The rule that avoids nearly all of this: if a function needs a value, take it as a parameter. If a function produces a value, return it. Reaching out to grab or change something is the exception and needs a reason. Lesson seven turns this into a proper principle.

The loud symptom is a ReferenceError saying the name is not defined. Something used a name that does not exist where it stands. Ask where the name was declared, then find the closing brace between there and here.

The quiet symptom is typeof reporting "undefined" for a name you are sure you declared. typeof is deliberately forgiving: it answers "undefined" for a name that was never declared at all instead of throwing. The worked examples use this to prove that locals really have vanished from the outside — a name being invisible and a variable holding undefined look identical through typeof, which is worth remembering when you use it to debug.

A block is a pair of braces, and let and const belong to the block they were declared in. Inner code can read outer names; outer code can never see inner ones. Redeclaring a name inside a block shadows the outer one for that block only and leaves it unchanged. Assigning to an outer variable from inside a function is a different thing entirely, and is the source of bugs that appear far from their cause.