Scope & lexical environments

Scope decides what names you can use

Scope is the part of a program where a name can be found. If you write console.log(total), JavaScript must answer a simple question before it can print anything: which binding named total is visible from this line?

The curriculum summary for this lesson is our map: global, function, and block scope, and how lookups climb the scope chain. You already saw block-scope basics in Variables and a first look at outer variables in Declaring & calling functions. Execution contexts gave names a home; Hoisting & the temporal dead zone explains why some names exist before a line can safely read them.

Lexical scope: where code is written

Lexical comes from words and text. In JavaScript, ordinary variable lookup is tied to the written shape of your code. If a function is written inside another function, it can read the outer function's variables because that is where the function was built.

This is why the Closures lesson opens with nested functions. This lesson is the foundation for that one: before a function can remember outer variables, you need to know which outer variables it can see.

A caller does not get to lend its local variables to a function just by calling it. In JavaScript, the function reads the environment from where it was defined. Dynamic scope, used by some languages and tools, would instead ask who called the function.

const label = "global";

function makeReader() {
  const label = "defined in makeReader";
  return function readLabel() {
    return label;
  };
}

const readLabel = makeReader();

function callFromAnotherPlace() {
  const label = "caller local";
  return readLabel();
}

console.log(callFromAnotherPlace());

The caller has its own label, but readLabel was created inside makeReader, so it reads that environment. The dynamic result in the playground is deliberately labeled hypothetical.

A block is code between braces: an if body, a loop body, or even a plain { ... } block. let and const live in the nearest block. The older var ignores ordinary blocks and belongs to the surrounding function or script.

if (true) {
  let blockLet = "inside if";
  const blockConst = "inside if";
  var functionVar = "var ignores this block";
}

console.log(functionVar);
// console.log(blockLet); // ReferenceError outside the block

Prefer the smallest useful scope. A temporary value used only inside an if or for block should usually be declared there, not at the top of a whole function.

When JavaScript reads an identifier, it starts in the current environment. If the name is not there, it walks outward one environment at a time. That outward path is the scope chain.

1const room = "global lobby";Run2 3function outer() {4  const room = "outer hall";5  function inner() {6    // no local room here7    return room;8  }9  return inner();10}11 12console.log(outer());

Turn on the inner declaration and replay. One line changes, but the lookup result changes because the closest room now has its own name tag. That is the core rule: nearest binding wins.

Shadowing happens when an inner scope declares a name already used by an outer scope. It is legal and often useful, but it can hide the value you meant to read.

JavaScript also has early errors for some confusing redeclarations. This one is a syntax error because var tries to create a function-scoped binding where let already declared the same name.

let x = "outer";
{
  var x = "same function scope";
}

Lexical environment records

The specification models scope with lexical environments. You can picture each environment as a record of bindings plus a reference to an outer environment. Function calls create function records; blocks create block records for let and const; modules create module records.

function makeGreeter(name) {
  const punctuation = "!";
  return function greet() {
    return "Hello, " + name + punctuation;
  };
}

const greetAda = makeGreeter("Ada");
console.log(greetAda());

In the model, the returned greet function keeps a reference to the environment record that has name and punctuation. That is exactly the bridge to the next lesson, Closures.

Where you use this

Scope rules guide everyday decisions:

• Put loop-only values inside the loop so later code cannot misuse them.
• Keep helper functions near the data they read, especially in modules.
• Avoid accidental globals by declaring every name with let, const, or var.
• Rename shadowed values when the duplicate name makes code harder to read.

Common misconceptions

Key takeaways

• Lexical scope is decided by where code is written.
• Lookup starts locally and walks outward along the scope chain.
• let and const are block-scoped; var is not.
• Shadowing means a nearer binding hides an outer binding with the same name.
• Environment records are the spec model: bindings plus an outer reference.

Up next: Closures.