Variables: let and const

A variable is a name for a value. Without them every program would have to recalculate everything from scratch each time it needed it, and nothing could remember anything.

const dish = "Biryani";
const price = 350;

console.log(dish, "costs", price, "rupees");

Biryani costs 350 rupees

Three lines: name a piece of text, name a number, then use both by name.

const first, let when you must

JavaScript gives you two words for making a variable, and there is a clear default.

const makes a name that cannot be pointed at something else:

const price = 350;
console.log(price);

350

Try to reassign it and the program stops:

const price = 350;
price = 400;

That produces TypeError: Assignment to constant variable. — the program does not limp on with a wrong value, it halts and tells you.

let makes a name you can point at something else later:

let total = 0;
total = total + 350;
total = total + 280;

console.log(total);

630

The habit worth forming: reach for const every time, and switch to let only when you actually need to reassign. Most variables in a normal program are never reassigned, so most of them should be const.

This is not fussiness. A const tells the next reader — usually you, later — that this name means the same thing everywhere below it. With let they have to scan the rest of the function to find out whether it changed. Fewer things that can move means less to hold in your head.

const does not freeze the value

This is the misunderstanding worth spending real time on, because the behaviour looks contradictory the first time you see it:

const order = { dish: "Biryani", quantity: 1 };

order.quantity = 3;

console.log(order);

{ dish: 'Biryani', quantity: 3 }

The object was declared const and it just changed. That is not a bug.

const protects the name, not the contents. Think of the name as a label stuck to a box. const means you cannot move the label to a different box. It says nothing about what is inside the box.

So this works — changing what is in the box:

const menu = ["Biryani", "Pulao"];
menu.push("Roti");

console.log(menu);

[ 'Biryani', 'Pulao', 'Roti' ]

And this fails — moving the label to a different box:

const menu = ["Biryani", "Pulao"];
menu = ["Roti"];

That is TypeError: Assignment to constant variable. again.

Once you have the label-and-box picture, the rule stops being surprising: const blocks =, and nothing else. Anything that reaches inside — push, setting a property — is untouched.

Naming

The rules JavaScript enforces are few. A name may contain letters, digits, $ and _, and may not begin with a digit. It cannot be a reserved word like const or return.

The conventions matter more than the rules, because they are what makes code readable:

const totalPrice = 1050;
const customerName = "Ayesha";
const isReady = true;

console.log(customerName, totalPrice, isReady);

Ayesha 1050 true

Names run together with each new word capitalised — totalPrice, not total_price or TotalPrice. This is camelCase, and it is universal in JavaScript.

Say what the thing is. price is better than p. totalPrice is better than price2. A name starting is or has signals a true/false value, which reads well in a condition: if (isReady).

Names are case sensitive, and this bites everyone once:

const dishName = "Biryani";
console.log(dishName);

Biryani

Write dishname instead and you get ReferenceError: dishname is not defined — a different name entirely, as far as JavaScript is concerned.

Why you will see var, and why not to write it

Older code uses a third word, var:

var price = 350;
console.log(price);

350

It still works and always will — the web does not break old pages. But it behaves in ways that cause bugs, and let and const were added specifically to fix them.

The clearest problem is scope. let and const are confined to the block they are declared in — the nearest { }. var is not; it leaks out to the whole surrounding function:

if (true) {
  var leaked = "I escaped the block";
  let contained = "I did not";
  console.log(contained);
}

console.log(leaked);

I did not
I escaped the block

leaked is still readable outside the if that created it. contained would throw a ReferenceError there. When two parts of a long function each declare var i, they are the same variable, and the resulting bugs are genuinely nasty to find.

So: recognise var when you read old code, and do not write it. There is no situation left where it is the better choice.

Declare, then use

A variable has to exist before you use it:

const dish = "Pulao";
console.log(dish);

Pulao

The other way round throws ReferenceError: Cannot access 'dish' before initialization. Top to bottom, as always.

One more thing that catches people: declaring the same const twice in the same scope is an error — SyntaxError: Identifier 'dish' has already been declared. If you want a new value, use let and reassign; if you want a new thing, give it its own name.

In practice

const pricePerPlate = 350;
let plates = 2;

let total = pricePerPlate * plates;
console.log("Two plates:", total);

plates = 3;
total = pricePerPlate * plates;
console.log("Three plates:", total);

Two plates: 700
Three plates: 1050

pricePerPlate never changes, so it is const. plates and total both do, so they are let. That distinction, applied consistently, is most of what makes JavaScript readable.

Next, types — what kinds of value these names can hold, and the difference between null and undefined that trips up nearly everyone. If the console.log habits here were new, go back to console.log.