A comment is text in your file that the JavaScript engine skips completely. It has no effect on what the program does, which means it exists for exactly one audience: the people reading the code later, including you.

There are two forms and the engine treats both as if they were not there.

Two slashes comment out the rest of the line:

// This whole line is a note.

let price = 20;   // A note can also sit after code.

Everything from the slashes to the end of the line is ignored. Code before them on the same line still runs normally.

A slash-star opens a comment that runs until a star-slash closes it:

/*
  This form covers as many lines as you like.
  Useful for a paragraph of explanation, or for
  switching off a whole block at once.
*/

const taxRate = 0.18;

The one trap in the second form is that it does not nest:

/* outer comment
   /* inner comment */
   this line is now read as CODE
*/

The first */ the engine meets closes the comment, whichever one you meant. Everything after it is parsed as real code, and you usually find out through a SyntaxError several lines further down. When in doubt, put // on each line instead; two slashes never have this problem.

Switching code off is a real technique, not laziness:

let total = 100;
// total = total * 1.18;
console.log(total);   // 100

When something breaks and the cause is not obvious, disabling half the lines to find which half is responsible is faster than staring at all of them. Narrow it down, find the line, then put the rest back.

The discipline that matters is deleting the dead lines once you have your answer. Commented-out code that stays in a file forever becomes noise that every reader learns to scroll past, and eventually nobody can tell which of it was a deliberate experiment and which is simply forgotten. If you might want it back, that is what version control is for.

One habit worth adopting from the start: a comment at the very top of a file, explaining what the file is for, is almost always worth writing. Not what it contains, which the code shows, but why it exists and what depends on it. That single paragraph is the difference between a file someone can safely change and one they work around because they cannot tell what would break.

The most common mistake in commenting is restating in English what the line already says perfectly well in JavaScript. The reader can see what the code does, because they are reading the code. What they cannot see is the reasoning that put it there.

A comment that adds nothing:

// increment count
count = count + 1;

// set the tax rate to 0.18
const taxRate = 0.18;

// print the total
console.log(total);

Each of those is the line again, in English, one line higher. Delete all three and the file loses no information at all.

A comment that earns its place:

// 0.18 is GST, set by the tax authority in 2017.
// If this changes, the invoice template needs updating too.
const taxRate = 0.18;

Nothing in the code could tell you that the number is a government rate, when it was set, or that something elsewhere depends on it. The comment is the only place that knowledge exists.

A useful test to apply before writing one:

Ask whether a competent reader could work it out from the code alone. If they could, the comment is noise. If they could not, it is the only record of something that matters. Reasons, constraints, decisions you argued about, and surprising behaviour in someone else's system all pass that test. Descriptions of what the line does almost never do.

Prefer a better name over a comment wherever you can:

const d = 86400;  // seconds in a day

That comment is doing the job a name should be doing. Fix the name and it becomes unnecessary:

const secondsPerDay = 86400;

A name travels with the value everywhere it is used. A comment sits in one place and explains a value that might be read in twenty others.

There is one more reason to prefer names. A comment that repeats the code goes stale the moment the code changes, and nothing forces anyone to update it. A stale comment is worse than no comment, because it actively lies to the next reader, who has no way of knowing which of the two to trust. A comment that captures a reason stays true for years, because reasons change far less often than implementations.

Pro Tip: If you find a comment hard to write, that is often a signal about the code rather than the comment. Needing a paragraph to explain what a function does usually means the function is doing several things and wants splitting.

A statement is one instruction. JavaScript runs them top to bottom, one at a time, and knowing where one ends and the next begins is what turns a wall of text into something you can read at a glance.

Semicolons end a statement, and are mostly optional:

let a = 1;
let b = 2;
console.log(a + b);   // 3

let c = 1
let d = 2
console.log(c + d)    // 3

Both work. JavaScript inserts the missing semicolons itself, following rules that are correct almost all of the time. The cases where it guesses differently from what you meant are rare and genuinely confusing, which is why the usual advice is to pick one style and never mix them. Most teams write the semicolons and let a formatter put them in automatically.

Whitespace is ignored by the engine entirely. These two are the same program:

const user={name:"Ada",age:36};

const user = { name: "Ada", age: 36 };

The engine cannot tell them apart. A person can tell them apart instantly, and that is the whole reason spacing matters. The second version shows you that there are two properties, where each one starts, and which value belongs to which name. The first makes you find the commas yourself.

The same applies to expressions, where spacing reveals the grouping:

const total = (price * quantity) + shipping - discount;

const total2 = (price*quantity)+shipping-discount;

Identical results. The first lets you see that the multiplication happens first, because the spaces around the lower-precedence operators separate the parts. The second is a single run of characters you have to parse one symbol at a time.

Indentation shows what belongs to what:

if (isLoggedIn) {
  showDashboard();
  loadNotifications();
}

hideSpinner();

Two spaces in means those lines belong to the if. Back out to the left margin means the line always runs, whatever the condition was. You can see the structure without reading a single word.

That is the useful way to think about formatting: the engine does not care, and that is precisely why it matters. Spacing is not for the computer. It is a message to the next reader about the shape of the program, and the quickest way to make code unreadable is to let the indentation and the actual structure disagree.

Two slashes comment one line, slash-star comments many. Comment the why, not the what, because a comment that restates the code goes stale and starts lying the moment the code changes.