var vs let and const

## What a declaration actually does Every declaration creates a *binding*: a name attached to a storage slot inside some environment record. The keyword you use decides **which** environment record gets that binding, and that choice is fixed statically when the source is parsed — nothing at runtime can move it. JavaScript has two answers to "which record?": - `var` binds into the nearest enclosing **function** scope. If there is no enclosing function, it binds into the script/global scope. Blocks — `if`, `for`, `while`, `switch`, `try`/`catch`, or a bare `{ }` — are not var scopes at all. - `let` and `const` bind into the nearest enclosing **block**. Every pair of braces creates a fresh block environment, including the head of a `for` loop and the body of a `switch`. ```js function f() { if (true) { var a = 1; let b = 2; } console.log(a); // 1 — a was never inside the if block; it belongs to f console.log(b); // ReferenceError: b is not defined } ``` The mental model that keeps this straight: with `var`, the braces are decoration; the only thing that carves out a new scope is a `function` boundary. ## Why var works this way Before ES2015 the language had no block-scoped declaration form at all — `var` and function parameters were the whole story, and function scope was the only granularity available. `let` and `const` were added in ES2015 with block scoping precisely because function-only scoping is a poor fit for the way people write loops and conditionals. `var` kept its old rules unchanged, because changing them would silently alter the meaning of existing code. ## Loops make the difference obvious ```js for (var i = 0; i < 3; i++) { /* ... */ } console.log(i); // 3 — i survives the loop for (let j = 0; j < 3; j++) { /* ... */ } console.log(j); // ReferenceError: j is not defined ``` With `var`, the counter is a variable of the whole function that the loop happens to use. With `let`, the counter belongs to the loop and nothing outside can see it. In a long function, a stray `var i` from a loop two hundred lines up is a name you can accidentally reuse or clobber; with `let` the engine tells you the name does not exist there. ## Blocks people forget are blocks A bare block is a real scope: ```js { let secret = 1; var open = 2; } console.log(typeof open); // "number" console.log(typeof secret); // "undefined" — secret never existed out here ``` A `switch` statement body is **one** block, not one block per `case`, so two `case` clauses cannot each declare `let x` — that is a duplicate declaration in the same scope. A `catch` clause's parameter is bound to the catch block and disappears with it. ## Functions still stop var `var` climbs out of blocks, but never out of a function: ```js function outer() { function inner() { var hidden = 1; } inner(); console.log(hidden); // ReferenceError } ``` This is the reason the old immediately-invoked-function idiom existed: wrapping code in a function was the only way to give `var` a boundary. With `let` and `const`, a plain `{ }` does the same job. ## Where this bites in real code The classic bug is a name reused for two purposes in one long function. With `var`, the second use quietly overwrites the first — the program keeps running and produces a wrong number. With `let`, the second declaration in the same scope is a hard error at parse time and the file does not run at all, which is exactly the feedback you want. The second common bug is a value computed inside a conditional and read afterwards. Code written with `var` gets away with declaring it inside the `if`; the same code converted to `let` breaks, and the correct fix is to declare the binding in the outer scope and assign inside the branch: ```js let result; if (condition) { result = compute(); } else { result = fallback(); } ``` ## The working rule Use `const` by default, `let` when the binding genuinely needs to be reassigned, and `var` essentially never in new code. `const` and `let` give you the narrowest scope the language can express, and the narrower the scope, the fewer lines of code can possibly be responsible when a value is wrong.