Variables — let, const, var

How to store information in JavaScript — and why const is the right default, let is for things that change, and var is legacy.

What it is, in plain English: A variable is a named container for a value. In modern JavaScript you declare variables with const (when the value won't change) or let (when it will). const is the right default — it makes your code easier to reason about. var is the old way; it has surprising scoping rules and is avoided in new code.

Where this bites you

Writing let again inside a block doesn't update the variable outside it. It creates a brand-new variable with the same name that exists only inside those braces (called shadowing). The outer variable is untouched, and when the block ends the inner one disappears with your result. JavaScript reports no error, because two variables in different scopes are perfectly legal.

const cart = [{ price: 120, member: true }, { price: 80, member: false }];
let discount = 0;

for (const item of cart) {
    if (item.member) {
        let discount = item.price * 0.1;   // meant to update the outer discount
        console.log("member discount:", discount);
    }
}

console.log("total discount:", discount);
// member discount: 12
// total discount: 0

Storing information in variables

Programs need to remember things. A variable is how you give a piece of information a name so you can use it later. Think of it like a labelled box — you put something in, you can take it out or look at it later by using the label.

Declaring a variable

The word "declare" just means "create." You declare a variable using const, let, or var, followed by the name you're giving it.

// const — for values that will NOT change
const greeting = "Hello, world!";
const maxScore = 100;
const pi = 3.14159;

// let — for values that WILL change
let currentScore = 0;
let playerName = "Alice";
let isGameOver = false;

The rule: use const by default

Here's the simple rule: start with const. Switch to let only if you need to reassign.

Why? Because if something can't change, it shouldn't change. const makes that explicit — if you or a colleague accidentally try to reassign it, JavaScript will throw an error immediately, before the bug causes mysterious problems further along.

const userName = "Alice";
userName = "Bob";   // ✗ TypeError: Assignment to constant variable
                    // JavaScript catches this immediately

let score = 0;
score = score + 10;   // ✓ let allows reassignment
score += 5;           // ✓ shorthand: score = score + 5
score++;              // ✓ shorthand: score = score + 1
console.log(score);   // 16

What const actually means — a common misconception

const means the variable binding is constant — you can't point the variable to a different value. But if the value is an object or array, the contents of that object or array can still change:

const person = { name: "Alice", age: 30 };

// ✓ Changing a property is fine — we're not reassigning person itself
person.age = 31;
person.city = "Mumbai";
console.log(person);   // { name: 'Alice', age: 31, city: 'Mumbai' }

// ✗ Reassigning person is not fine
person = { name: "Bob" };   // TypeError: Assignment to constant variable

Think of const as "the label is stuck on this box" — you can change what's inside the box, but you can't point the label at a different box.

Naming variables well

Choose names that describe what the variable holds. This is one of the most important habits in programming.

// ✗ Bad: what does x mean? What is d?
let x = 9.99;
let d = 0.1;
let t = x + (x * d);

// ✓ Good: instantly readable
const itemPrice = 9.99;
const taxRate = 0.1;
const totalPrice = itemPrice + (itemPrice * taxRate);
console.log("Total:", totalPrice);   // Total: 10.989

JavaScript convention: camelCase — first word lowercase, each new word capitalised. firstName, totalScore, isUserLoggedIn. Constants that are genuinely fixed configuration values sometimes use UPPER_SNAKE_CASE: MAX_RETRIES, API_BASE_URL.

What happens if you use a variable before declaring it?

console.log(age);   // ✗ ReferenceError: Cannot access 'age' before initialisation
const age = 25;

With const and let, you get a clear error. Always declare before use. (With var it would print undefined instead of erroring — one of the reasons var is avoided.)

Try It Yourself

Scope, hoisting, and the temporal dead zone

Scope — where a variable is visible

Scope is the region of code where a variable exists and can be used. let and const are block-scoped: they only exist inside the { } block where they're declared.

function calculateTax(price) {
  const taxRate = 0.1;       // only visible inside calculateTax
  const tax = price * taxRate;
  return tax;
}

console.log(calculateTax(100));  // 10
console.log(taxRate);           // ✗ ReferenceError: taxRate is not defined

// Block scope with let
if (true) {
  let blockVariable = "I'm inside the if";
  console.log(blockVariable);  // ✓ works
}
console.log(blockVariable);   // ✗ ReferenceError — out of scope

// const and let in loops:
for (let i = 0; i < 3; i++) {
  // i is scoped to this loop block
  setTimeout(() => console.log(i), 100);   // prints 0, 1, 2 ✓
}

That's block scope from the examples above, working exactly as designed: the inner let discount belongs to the if block. To change the outer variable, assign to it without declaring a new one. (Linters can flag shadowing with ESLint's no-shadow rule.)

const cart = [{ price: 120, member: true }, { price: 80, member: false }];
let discount = 0;

for (const item of cart) {
    if (item.member) {
        discount = item.price * 0.1;       // assigns the outer variable
        console.log("member discount:", discount);
    }
}

console.log("total discount:", discount);
// member discount: 12
// total discount: 12

var — function scope and why it's avoided

var is function-scoped, not block-scoped. It ignores if, for, and any other block — it leaks up to the nearest function.

function example() {
  if (true) {
    var leaked = "I leaked!";   // var ignores the if block
    let notLeaked = "I stayed";
  }
  console.log(leaked);     // ✓ "I leaked!" — var escaped the if block
  console.log(notLeaked);  // ✗ ReferenceError — let stayed in the block
}

// The classic for-loop bug with var:
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);  // prints 3, 3, 3 ✗
}
// Why? var i is shared; by the time setTimeout fires, the loop is done and i=3.
// Fix: use let instead of var.

Hoisting

Hoisting is JavaScript's behaviour of moving declarations to the top of their scope before execution. All three keywords are hoisted, but differently:

// var is hoisted AND initialised to undefined:
console.log(x);   // undefined (no error — x exists but has no value yet)
var x = 5;
console.log(x);   // 5

// let and const are hoisted but NOT initialised:
console.log(y);   // ✗ ReferenceError: Cannot access 'y' before initialisation
let y = 5;

// Function declarations are fully hoisted (body and all):
greet();   // ✓ works — function is available before its declaration
function greet() { console.log("Hello!"); }

// Function expressions are NOT fully hoisted:
sayBye();  // ✗ TypeError: sayBye is not a function
const sayBye = function() { console.log("Bye!"); };

The Temporal Dead Zone (TDZ)

The period between entering a scope and the point where a let/const variable is declared is called the Temporal Dead Zone. Any access to the variable in the TDZ throws a ReferenceError. This exists precisely to catch bugs that var's silent undefined hoisting would hide.

function tdz() {
  // TDZ starts here for `name`
  console.log(name);   // ✗ ReferenceError — in the TDZ
  let name = "Alice";  // TDZ ends here
  console.log(name);   // ✓ "Alice"
}
tdz();

Environment records, binding semantics, and const internals

Environment Records (ECMA-262 §9.1)

The spec models variable scope using Environment Records — data structures that map identifier names to bindings. Each has an outer reference forming a chain (the scope chain). Types:

Declarative Environment Record — stores let, const, function, class bindings
Object Environment Record — wraps an object (used by with statements and the global object for var)
Global Environment Record — wraps the Object ER (for globals) and a Declarative ER (for top-level let/const)
Function Environment Record — adds this binding and super
Module Environment Record — extends Declarative ER with import bindings

Binding states

A binding in an Environment Record can be in one of these states:

Uninitialized — created by hoisting but not yet assigned (let/const TDZ state). Accessing → ReferenceError
Initialized — has a value (even if undefined for var at hoist time)
Mutable vs Immutable — const creates an immutable binding; reassignment → TypeError at the binding level (not the value level)

How const prevents reassignment

const creates an immutable binding in the Environment Record. The SetMutableBinding abstract operation checks whether the binding is mutable; for const bindings, it throws a TypeError if called with the S (strict) flag — which is always set in modern code. The value itself (e.g. an object) is unaffected — the binding just can't be pointed elsewhere.

var vs let: the Global Object relationship

Top-level var declarations create properties on the global object (window in browsers, global in Node.js). Top-level let and const do not — they go into the Declarative ER of the Global Environment Record. This is why:

var topVar = 1;
let topLet = 2;

console.log(window.topVar);   // 1 — on the global object
console.log(window.topLet);   // undefined — NOT on the global object

This means var pollutes the global namespace in a way let/const do not.

Temporal Dead Zone — the spec mechanism

In the spec, hoisting for let/const means the binding is created in the Environment Record at function/block entry via CreateMutableBinding (let) or CreateImmutableBinding (const), but InitializeBinding is not called until the variable declaration is evaluated. Accessing an uninitialized binding calls GetBindingValue, which checks the initialized state and throws ReferenceError if false. This is defined in ECMA-262 §9.1.1.1.6.

Official Sources

The Codex links only to official documentation and the ECMAScript specification. No third-party tutorials.