Code structure

Before you can write anything interesting, you need to know how the pieces of a program fit together. A script is not one long blob of instructions the engine reads as a paragraph. It’s a sequence of small, self-contained commands, and JavaScript has a few rules about where one command ends and the next begins. Get those rules slightly wrong and the code can still look fine while behaving in a way you never intended.

This chapter is about that skeleton: statements, the semicolons that separate them, and the comments you leave for the humans reading later.

Statements

A statement is a single instruction — a piece of syntax that tells the engine to do something.

You’ve already met one. Back in the first examples, alert('Hello, world!') popped up a box on screen. That whole line is a statement: an action the engine carries out.

A program is just a list of these, run top to bottom. You can have as many as you like, and you separate them with a semicolon.

Here’s a pair of messages split into two separate actions, both crammed onto one line:

alert('Ping'); alert('Pong');

That runs perfectly well. But nobody writes code that way. Give each statement its own line and the program becomes far easier to scan:

alert('Ping');
alert('Pong');

1 ▸alert(‘Ping’);

2 ▸alert(‘Pong’);

runs in order ↓

Semicolons

Here’s where it gets interesting. In most cases you can leave the semicolon off when there’s a line break, and the code still works:

alert('Ping')
alert('Pong')

JavaScript reads the line break and quietly treats it as an “implicit” semicolon. The official name for this behavior is automatic semicolon insertion — often shortened to ASI. The engine tries to figure out where you meant a statement to end and inserts the semicolon for you.

A newline usually implies a semicolon. But “usually” is not “always” — and that gap is the entire reason this section exists.

Sometimes a line break clearly does not end a statement, and JavaScript gets it right. Consider:

alert(4 +
2
+ 3);

This prints 9. The engine never inserts a semicolon in the middle, because after 4 + the expression is obviously incomplete — a line ending in + is begging for another operand. Stopping there would be nonsense, so the engine reads on. Good instinct, correct result.

✔ line ends complete

alert(‘Ping’)

← semicolon inserted here

alert(‘Pong’)

✘ line ends open

alert(4 +

← no semicolon, expression open

2 + 3);

The trouble is the other direction: the times JavaScript fails to insert a semicolon where you genuinely needed one. Those bugs are nasty precisely because the code looks correct. The syntax is valid, nothing throws where you’re looking, and the behavior is just… wrong.

So here’s the practical rule, and it’s the one the wider JavaScript community has largely settled on: put a semicolon after every statement, even when a newline would let you skip it. Yes, you can omit them most of the time. But “most of the time” leaves a handful of traps, and none of them announce themselves. Especially while you’re learning, the semicolons cost you nothing and save you from a class of bug that’s genuinely hard to spot.

Comments

Programs grow. What was obvious the day you wrote it becomes a puzzle three months later, and it’s an outright mystery to the next person who opens the file. Comments are the notes you leave to explain what the code does and, more importantly, why.

The engine ignores comments completely. You can put them anywhere, and they never affect how the program runs — they exist purely for human readers.

Single-line comments start with two slashes, //. Everything after them on that line is a comment. It can sit on its own line or trail a statement:

// This comment occupies a line of its own
alert('Ping');

alert('Pong'); // This comment follows the statement

Multiline comments open with a slash-asterisk /* and close with an asterisk-slash */. Everything between them is ignored, across as many lines as you want:

/* An example with two messages.
This is a multiline comment.
*/
alert('Ping');
alert('Pong');

alert(‘x’); // to end of line →→→

/* from here …

… any number of lines …

… to here */

Because the content between /* … */ is ignored, you can wrap actual code in it to switch that code off. This “commenting out” trick is handy when you want to temporarily disable a chunk without deleting it:

/* Commenting out the code
alert('Ping');
*/
alert('Pong');

Only Pong runs here — the alert('Ping') is sealed inside the comment.

Don’t be shy about commenting. A common worry is that comments bloat the file — and technically they do add bytes. But that cost never reaches your users. Production builds run through minifiers, tools that strip comments and whitespace before the code ships. The comments help you and your teammates during development, then vanish from the version the browser actually downloads.

source (you)

// why this exists

doThing();

— minify →

shipped (users)

doThing();

There’s more to say about what makes a good comment versus a useless one — the difference between explaining “why” and narrating the obvious. A later chapter on code quality digs into that. For now, the habit to build is simple: leave notes for the reader who comes after you, because that reader is often future you.