Naming values: let and const

So far every value has been used the instant it was made. That does not scale past two lines. A DECLARATION makes a value and ties a name to it, so the rest of the program can refer to it without repeating how it was worked out.

The shape is always the same: the keyword, the name, an equals sign, and an expression. Read the equals sign as the word becomes, never as the word equals — it is an instruction to attach, not a claim that two things are the same. That reading also stops you from writing a single = where you meant a comparison.

Naming is not decoration. The moment a value has a name, the intent of the line above it is recorded permanently, in the one place nobody can forget to update: the code itself.

const declares a name that cannot be pointed at a different value afterwards. It must be given a value at the moment you declare it — a const with nothing after the equals sign is not allowed, because there would be no later opportunity to supply one.

let declares a name you can point at a new value later, by writing the name, an equals sign and the new expression. No keyword the second time: the keyword is what creates the name, and it happens once.

The working rule, and it is close to universal in modern JavaScript: start with const every time, and change it to let only when you write a line that has to reassign it. This is not fussiness. A const tells every future reader, in one word and at a glance, that this value is fixed for the rest of its life — so when they are hunting for what changed a value, they can skip it entirely.

There is an older keyword, var, in a great deal of existing code. It behaves differently in ways that caused enough bugs for the language to add two replacements, and the honest summary is: read it when you meet it, do not write it. The module on functions explains what it actually does, once scope exists to explain it with.

Picture a name as a luggage tag tied to a suitcase. const means the tag cannot be untied and moved to a different suitcase. It says nothing at all about what is inside this one.

For the values in this module — numbers, text, booleans — the distinction never shows up, because none of them can be altered from the inside anyway. It matters enormously for the collections in module 4: a const array can have items added to it all day, because the tag is still on the same array. If that sounds like a contradiction now, park it. The wording to keep is the one that stays true either way: const stops reassignment, not change.

The rules are few. A name may contain letters, digits, underscores and dollar signs; it may not start with a digit; it is case-sensitive; and it may not be one of the language's own keywords, so const const is out.

The conventions matter more than the rules, because they are what makes code readable across a whole industry. JavaScript names run words together with a capital at the start of each after the first: unitPrice, totalCents, isOutOfStock. That style is called camelCase. Nothing enforces it, and everyone follows it.

Beyond that, the rule of thumb: a name should say what the value IS, not how it was computed or what type it is. total beats t and beats totalNumber. Booleans read best as a claim — isReady, hasStock. Names are free, and a longer one that removes a question is always the better deal.

Reassigning a const. The specification says this raises a TypeError, and the program stops on that line — some engines notice even earlier, while reading the file, and refuse to start it at all. Either way you get told immediately, which is the whole benefit: the alternative is a value quietly changing under you at three in the morning.

Declaring the same name twice in the same scope. Writing let total twice, or const after let, is a SyntaxError — an error found while the code is being read, before a single line runs. If you meant to change the value, drop the second keyword and just assign.

Using a name on a line above its declaration. Names declared with let and const are not usable before the line that declares them; touching one early stops the program with a ReferenceError rather than quietly giving you nothing. Declare a value just above where you first need it, and the problem never arises.

Ask a room of professionals what makes code good and naming will come up before anything technical. The reason is arithmetic: a line of code is written once and read dozens of times, and every read is faster when the names say what they mean.

There is a debugging payoff too. When something is wrong with a value, the first question is always where did this change? const answers that question for every name it guards, permanently and without you having to look. A file where only three names are let is a file with only three places worth searching.

A declaration ties a name to a value: read = as becomes. Use const by default; it must be initialised and cannot be reassigned, though it does not freeze what is inside a collection. Use let only where a reassignment actually happens, and write the keyword only once. Names are camelCase and should say what the value is.