Block Scope and Shadowing

Concept

A block is simply any code between { } — an if, a for loop, or just a bare { } on its own. let and const treat that boundary as a real wall. var ignores it completely. That one difference is the entire lesson — and it has a sharp edge called shadowing that can genuinely break your code if you don't know it's there.

Key Words In Plain English

• Scope is the part of the code where a name can be used. Outside its scope, the name does not exist.
• Block is a group of statements inside curly braces. It is a scope for let and const, but not for var.
• Lexical Environment is the engine's internal record of the variables of one scope, plus a link to the outer scope. “Lexical” means decided by where the code is written.
• Scope chain is the list of scopes from the inner one out to Global. When you use a name, the engine looks in the inner scope first, then the next one out, and stops at the first match.
• Shadowing is when an inner scope declares a name that an outer scope already has. The inner one hides the outer one while the code is inside.
• Hoisting is the engine reserving memory for declarations before any line runs. var is hoisted to the top of its function, not to the top of its block.
• Temporal Dead Zone (TDZ) is the time between a let/const name being reserved and its declaration line running. Reading the name in that time throws a ReferenceError.
• Parameter is a name in a function's definition, such as guestName in function checkIn(guestName). The value you pass when you call the function is the argument.
• SyntaxError is an error for code that is not valid JavaScript. The engine finds it before running any line.
• Linter is a tool that reads your code and warns about mistakes and risky patterns without running it. ESLint is the most common one for JavaScript.

Why This Matters

• It explains why the same variable name can safely repeat inside nested if blocks with let, but silently corrupts data with var.
• It's a very common real bug: a var inside a loop or an if block quietly overwriting a variable you thought was separate.
• It's a frequent interview trap — predicting the output of nested blocks with repeated names.
• It closes the loop on Lessons 7 and 8: a block is a link in the scope chain, with its own TDZ for anything declared inside it. Once you can see the environment a block creates, every shadowing rule in this lesson follows from Lesson 7's “nearest match wins”.

The Meeting Room Door — An Analogy

What Counts As A Block

{
  // a bare block — still a block
}

if (true) {
  // this counts too
}

for (let i = 0; i < 3; i++) {
  // and this
}

Any { } counts — it doesn't need to be attached to an if or a loop.

Two braces that look like blocks but are not: the { } of an object literal ({ name: "Aditi" }) is a value, not a scope; and the body of a function is technically a function scope — it contains everything a block scope does, plus it is the one boundary var respects.

What A Block Actually Creates In Memory

A block is not a scope by decoration; it is a scope because entering it can create a real Lexical Environment (Lesson 7): a memory record for the block's own let/const/class declarations (and function declarations written inside the block), plus an outer reference to the environment the block sits inside. Leaving the block discards that environment. Everything else in this lesson is a consequence of that one object existing — or not.

{
  // no let/const here → the engine creates no environment for this block
  var x = 1;
}

{
  let y = 2;   // → a real block environment is created on entry, discarded on exit
}

The first block declares nothing block-scoped, so the engine has nothing to put in a block environment and creates none; the var was hoisted to the enclosing function long before the braces were reached. The second block declares a let, so on entry it gets an environment holding y (locked in its TDZ until line 7 runs — Lesson 8), and on exit that environment is dropped.

var vs. let/const Inside A Block

{
  var a = 10;
  let b = 20;
}

console.log(a); // 10 — var walked straight out
console.log(b); // ReferenceError — let stayed inside, now gone

Nested Blocks — The Chain, One Brace At A Time

Blocks nest, and each nested block that declares something gets its own environment, whose outer reference points at the enclosing block's environment. The result is the same scope chain Lesson 7 built out of functions — just with braces as the links.

let floor = 1;
{
  let wing = "north";
  {
    let room = 101;
    console.log(room, wing, floor); // 101 north 1
  }
}

1let floor = 1;
2{
3  let wing = "north";
4  {
5    let room = 101;
6    console.log(room, wing, floor);
7  }
8}

Nothing new is happening here: room is found locally, wing one hop up, floor two hops up. The point is that a block is a first-class link in that chain, indistinguishable from a function's scope as far as lookup is concerned. Which is exactly why shadowing behaves the way it does.

Shadowing — When Names Repeat

Shadowing is what happens when an inner scope declares a variable with the same name as one in an outer scope. With let/const, this is completely safe:

let discount = 100;
{
  let discount = 20; // a genuinely separate variable, in its own block
  console.log(discount); // 20
}
console.log(discount); // 100 — untouched

Two totally separate discounts, living in two separate memory spaces. The inner one temporarily “shadows” the outer one, but never touches it.

In chain terms: the block environment has its own discount, so any lookup from inside the block stops at the first level — nearest match wins — and the outer binding is never consulted. It is not hidden by any special rule; it is one link further down a chain the lookup never walks.

Why var Shadowing Is Dangerous

var discount = 100;
{
  var discount = 20; // NOT a separate copy — this is the same variable
}
console.log(discount); // 20, not 100!

1let discount = 100;
2{
3  let discount = 20;
4  console.log(discount);
5}
6console.log(discount);

1var discount = 100;
2{
3  var discount = 20;
4  console.log(discount);
5}
6console.log(discount);

Illegal Shadowing — The One Combination That Throws

let discount = 100;
{
  var discount = 20; // SyntaxError: Identifier 'discount' has already been declared
}

This one specifically fails. var tries to attach itself to the nearest function/global scope — but a let with the same name already exists right there, and the two can't coexist. Every other combination is fine:

The mechanism is Lesson 8's redeclaration rule, seen from a new angle. The engine hoists var discount out of the block to the nearest function scope — here, Global. Global already holds a let discount. That is two declarations of one name in one scope, which is exactly the duplicate-let SyntaxError — caught at parse time, before any line runs. The braces did not protect the var, because braces never do.

The Function-Boundary Exception — Why The Same Pair Is Legal There

Read the previous rule carefully and a loophole appears: the collision happens only because the var hoists to the same scope as the let. Put a function boundary between them and the var hoists to the function instead — a different scope, no collision, ordinary shadowing.

let discount = 100;

function applyOffer() {
  var discount = 20;     // fine — this var belongs to applyOffer, not to Global
  console.log(discount); // 20
}

applyOffer();
console.log(discount);   // 100 — the outer let was never in the same scope

Same keywords, same names, same nesting — but the inner declaration is inside a function body rather than a bare block, so var discount belongs to applyOffer's own memory. The outer let is one link up the chain, untouched. So the precise statement of the illegal case is: a var may not hoist into a scope that already has a let/const of the same name. A block cannot stop that hoisting; a function can.

Shadowing Parameters And Built-Ins

A function's parameters live in the same scope as the top level of its body. That makes a parameter behave like a let declared just before the first line of the function body — so redeclaring it with let at the top level of the body is a duplicate declaration, while shadowing it inside a nested block is legal.

function checkIn(guestName) {
  let guestName = "Rahul";     // SyntaxError — the parameter already owns this name
}

function checkOut(guestName) {
  {
    let guestName = "Rahul";   // fine — a nested block is a different scope
    console.log(guestName);    // "Rahul"
  }
  console.log(guestName);      // the original argument, untouched
}

The same logic covers built-in names. let undefined = 5; at the top level of a classic browser script is a SyntaxError, because undefined is already a property of the global object; inside a block or a function it is legal, and creates a genuinely separate binding that shadows the real one for that scope. Legal is not the same as wise — shadowing undefined, name, length or event is a reliable way to confuse the next person to read the code.

The switch Trap — One Block For Every Case

A switch statement has exactly one block: the braces after switch (…). case labels are labels — they do not open a scope. So two cases that each declare let rate are two declarations in one scope, and that is a SyntaxError before the file runs.

switch (roomType) {
  case "single":
    let rate = 100;   // declared in the switch's one shared block
    break;
  case "double":
    let rate = 180;   // SyntaxError: Identifier 'rate' has already been declared
    break;
}

// the fix: give each case its own braces
switch (roomType) {
  case "single": {
    let rate = 100;
    break;
  }
  case "double": {
    let rate = 180;
    break;
  }
}

The fix is the general one: if you want a scope, write braces. Wrapping each case body in { } gives every case its own block environment, and the shared-block problem disappears. Linters flag the unwrapped version as no-case-declarations.

When Shadowing Is A Smell, And When It Is Fine

Everything above describes what the engine allows. What you should do is a narrower question.

• Fine: short-lived names in small, obviously separate scopes — the i of two sibling loops, an error in two separate catch blocks, a callback parameter that reuses a conventional name.
• Smell: shadowing a name from an enclosing scope that is still in use around the inner scope. Anyone reading the inner code has to remember which discount they are looking at, and a later refactor that removes the inner declaration silently changes which binding the inner code touches — from a private copy to the outer original.
• Always a bug: var “shadowing” inside a block. It looks like a separate variable and is not. Modern code avoids var entirely (Lesson 8), which removes this class of bug outright.

See It Live — DevTools

1. Paste the var-shadowing example

   The one under “Why var shadowing is dangerous,” into the console.

2. Set a breakpoint inside the block

   On the line var discount = 20;.

3. Check the Scope panel

   Notice there's only one discount listed, under the outer scope — not two. Stepping past this line updates that single value from 100 to 20, live.

4. Repeat with the let version

   This time the Scope panel shows two genuinely separate entries while paused inside the block — the outer discount untouched, a second one local to the block.

5. Look for the Block entry itself

   In the let version the panel gains a section titled Block while you are paused inside the braces, holding the inner discount. Step past the closing } and the whole Block section vanishes — that is the block environment being discarded. In the var version there is never a Block section at all, because no environment was ever created.

Common Misconceptions

Interview Questions