Block Scope and Shadowing in JavaScript

JavaScript's execution model handles variables differently depending on how and where they are declared. Understanding how standalone blocks, compound statements, and lexical scoping boundaries interact with var, let, and const is essential for writing predictable code and avoiding variable leakage or accidental mutations.

1. What Is a Block?

In JavaScript, a block (also known as a compound statement) is defined by a pair of curly braces ({ ... }).

{
    // This is a valid JavaScript block
}

A standalone pair of curly braces is completely valid JavaScript syntax.

Why Do We Need Blocks?

The primary purpose of a block is to group multiple JavaScript statements into a single syntactic unit. JavaScript often expects a single statement in specific control structures (such as if, while, or for). When developers need to execute multiple statements within those structures, they group them using a block.

// A single statement is valid:
if (true) true;

// If we need multiple operations, JavaScript requires a compound statement (block):
if (true) {
    const message = "Hello";
    console.log(message);
}

Note: A block groups statements together so that they can be used anywhere JavaScript expects a single statement.

2. Block Scope Demystified

Block scope determines what variables and functions are accessible strictly within a specific block.

To inspect how the JavaScript engine treats variable declarations inside a block, consider this example:

{
    var a = 10;
    let b = 20;
    const c = 30;
}

When this snippet runs in a browser debugger (e.g., Chrome DevTools), pause execution inside the block to see how memory is allocated:

Scope Allocation Differences

• let and const are block-scoped: During the memory creation phase, they are hoisted into a distinct memory partition reserved exclusively for that block. Once execution leaves the block, this space is wiped.
• var is NOT block-scoped: var declarations are hoisted directly into the nearest enclosing function scope or onto the Global Scope. They ignore block delimiters entirely.

3. Variable Accessibility Outside the Block

Because let and const reside inside the block scope, attempting to read them outside their block boundaries results in a runtime error. In contrast, var escapes the block boundary.

{
    var a = 10;
    let b = 20;
    const c = 30;

    console.log(a); // 10
    console.log(b); // 20
    console.log(c); // 30
}

console.log(a); // 10 (accessible because 'a' sits in the Global scope)
console.log(b); // Uncaught ReferenceError: b is not defined
console.log(c); // Never reached due to the previous Uncaught ReferenceError

Execution Flow

4. Variable Shadowing

Variable shadowing occurs when a variable declared in an inner scope has the same identifier (name) as a variable declared in an outer scope. The inner variable overlaps or "shadows" the outer variable within the boundaries of that inner scope.

Shadowing with var

When shadowing a var with another var inside a block, both identifiers point to the exact same memory allocation:

var a = 100;
{
    var a = 10; // Shadows the outer 'a'
    console.log(a); // 10
}
console.log(a); // 10 (the outer variable was overwritten!)

Because var is not block-scoped, var a = 10 does not create a new variable. Instead, it reassigns the existing a in the Global Scope. The inner statement mutates the outer variable permanently.

Shadowing with let and const

Block-scoped variables behave differently during shadowing:

let b = 100;
{
    let b = 20; // Shadows outer 'b' safely
    const c = 30;
    console.log(b); // 20 (reads from Block Scope)
}
console.log(b); // 100 (reads from Script/Outer Scope)

In the debugger, these two declarations occupy two completely separate memory environments:

1. Script Scope: Holds the outer variable (let b = 100).
2. Block Scope: Holds the inner variable (let b = 20).

When execution exits the block, the block scope is discarded, leaving the outer b unchanged.

5. Scope Comparison: var vs let vs const

6. Illegal Shadowing

Shadowing must respect scope boundaries. You cannot declare a variable that crosses its allowed boundary and collides with an existing identifier in the same scope.

The Illegal Case: Shadowing let with var

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

Why does this happen?

• var is function-scoped (or global). It ignores the block boundary and attempts to hoist itself into the surrounding scope.
• In the outer scope, let a is already declared.
• Declaring a var with the same identifier in the same scope violates the rule that let variables cannot be re-declared.

The Legal Counterpart: Shadowing var with let

var a = 20;
{
    let a = 100; // Completely valid
    console.log(a); // 100
}
console.log(a); // 20

This works because let stays confined inside the block scope. It does not cross the block boundary or attempt to re-declare a in the outer scope.

The Function Boundary Exception

A var inside an inner block can shadow an outer let if it is wrapped in its own function scope:

let a = 20;

function test() {
    var a = 50; // Legal! Confined to test()'s function scope
    console.log(a); // 50
}

test();
console.log(a); // 20

Here, var a is confined to test() and does not bleed into the outer scope where let a lives.

7. Lexical Scoping Inside Blocks

Blocks also follow lexical scoping rules. A block retains access to its parent environment, and nested blocks resolve identifiers by walking up the lexical scope chain.

const a = 20;
{
    const a = 100;
    {
        const a = 200;
        console.log(a); // 200 (resolved in current block scope)
    }
    console.log(a); // 100 (resolved in intermediate block scope)
}
console.log(a); // 20 (resolved in outer script scope)

If an identifier does not exist within the current block, JavaScript looks outward through each enclosing lexical environment until it reaches the global scope:

const a = 20;
{
    {
        {
            console.log(a); // 20 (traverses upward to outer scope)
        }
    }
}

8. Arrow Functions vs Normal Functions Regarding Scoping

Scope and variable resolution rules work identically in traditional functions and arrow functions:

// Traditional Function Expression
const fnOne = function () {
    var x = 10;
    let y = 20;
};

// Arrow Function
const fnTwo = () => {
    var x = 10;
    let y = 20;
};

Both constructs establish their own function-level execution context and lexical boundaries. Variables declared with var, let, and const behave identically across both formats.

Note: While arrow functions handle this binding differently, their lexical scope chain resolution for identifiers follows the exact same rules as standard functions.

Summary and Key Takeaways

• Blocks Group Statements: A block ({ ... }), also called a compound statement, groups multiple statements where JavaScript expects only one.
• Block Scoping: Variables declared with let and const are bound to the nearest enclosing block and cannot be accessed outside it.
• var Ignores Blocks: var declarations are scoped to their enclosing function or the global execution context, ignoring block boundaries entirely.
• Mechanism of Shadowing: An inner variable shadows an outer variable of the same name within the inner scope.
• Mutation via Shadowing: Shadowing a global var with another var in a block modifies the original memory reference. Shadowing with let or const creates an independent binding that leaves the outer variable intact.
• Illegal Shadowing Rule: You cannot shadow an outer let with a var within the same functional scope boundary, as the var hoists and triggers a duplicate-declaration SyntaxError.
• Legal Shadowing Direction: Shadowing an outer var with a block-scoped let is fully supported and safe.
• Lexical Resolution Across Nested Blocks: Identifier lookups traverse inward to outward across nested blocks until the global environment is reached.
• Parity Across Function Styles: Block and lexical scoping rules apply identically to both standard function declarations and ES6 arrow functions.