Repeating work with for and while

Suppose you have four test scores and you want their total. With what you already know you could write it out by hand: take the first score, add the second, add the third, add the fourth. That works. Now suppose there are four hundred scores, or that you do not know how many there are until the program runs. Writing it out by hand stops being possible, and the version you already wrote is wrong the moment someone adds a fifth score.

A loop is the tool for that situation. It lets you write the repeated step exactly once and tell the computer how many times to perform it. The step is written once, so there is one place to fix when it is wrong — which is the real reason loops matter. Copy-pasted work has to be corrected everywhere it was pasted.

This lesson covers the two oldest and most general loops in JavaScript: for and while. Later lessons in this module replace many of these loops with shorter, clearer methods. You still need this lesson first, because those methods are built on exactly this idea, and because a plain loop remains the right answer often enough that you should be able to write one without thinking about it.

Picture a paper shopping list and your finger resting on the first line. You read the line your finger is on, do something about it, then move your finger down one line. When your finger goes past the last line, you stop.

That is the whole mechanism. Three things are moving: where your finger is, what you do at each line, and the rule that tells you when to stop. Every counting loop you will ever write is those same three things, and when a loop misbehaves it is almost always because one of the three is wrong — the finger starts in the wrong place, moves the wrong way, or the stopping rule lets it run one line too far.

A for loop puts those three things on one line, separated by semicolons: for (initialization; condition; afterthought) followed by a block. Read it left to right as: start here; keep going while this is true; do this after each pass.

The order the engine uses is worth memorising, because it explains every result you will ever see. The initialization runs once, before anything else. Then the condition is evaluated; if it is truthy the block runs, and if it is falsy the loop is over and the program continues after it. After the block finishes, the afterthought runs, and then the condition is evaluated again. Notice what that means: the condition is checked before the first pass, so a loop whose condition starts out false runs its body zero times.

Declaring the counter with let inside the header keeps it local to the loop — the name does not exist after the loop ends. That is usually what you want. It also means each pass of the loop gets its own copy of that variable, which will matter when you combine loops with functions later on.

Array positions start at 0, so the last position of an array is always its length minus one. A three-item array has positions 0, 1 and 2, and its length is 3. Reading position 3 is not an error in JavaScript — it quietly gives you undefined, which is exactly why this class of bug survives long enough to reach a user.

That is why the standard counting loop over an array is written with a strictly-less-than condition: start the counter at 0 and keep going while it is less than the length. The counter then takes the values 0, 1 and 2 for a three-item array and stops before reaching 3. If you write less-than-or-equal instead, the loop takes one extra pass and reads a position that is not there.

A for loop suits work you can count before you start: once per array element, ten times, however many times. Some work cannot be counted in advance. How many times must you halve a number before it drops below a hundred? You do not know until you have done it.

while takes only a condition. It evaluates the condition, runs the block if the condition is truthy, and repeats. There is no counter unless you make one, and nothing changes between passes unless your own code changes it. That is the whole difference: a for header promises to move something after every pass, and a while loop promises nothing.

There is a close relative, do...while, that runs its block once before testing the condition, so its body always runs at least once. It is rare in practice. Reach for while first, and only use do...while when the first pass genuinely must happen no matter what the condition says.

Two keywords change a loop's flow from inside its body. break ends the loop immediately: no further passes, no further condition checks, execution resumes after the loop. Use it when you have found what you were looking for and the remaining work is pointless.

continue is narrower. It abandons the rest of the current pass and moves on to the next one. In a for loop the afterthought still runs before the next condition check, so the counter still advances. In a while loop there is no afterthought, so continue jumps straight back to the condition — and if the thing that was supposed to change lived after the continue, nothing changes and the loop runs forever. That is the single most common way a while loop hangs.

Off by one. The loop runs one pass too many or one too few, usually because the condition used less-than-or-equal where it needed less-than. The symptom for an array is an undefined appearing where you expected a value, and any arithmetic you then do with it produces NaN. When a loop over an array produces one bad result at the very end, check the condition first.

The loop that never ends. The condition never becomes falsy, so the program hangs. The two usual causes are forgetting to change the variable the condition tests, and changing it in the wrong direction. In this product the run pad has a wall-clock deadline and will stop a runaway loop and tell you it timed out, so you cannot lock up the page — but the fix is always the same: find the variable the condition depends on and make sure something in the body moves it toward the exit.

A habit that prevents both: before you run a new loop, say out loud what the counter is on the first pass, what it is on the last pass, and what makes the condition finally fail. If you cannot answer all three, the loop is not finished.

Beginners often read i as if it were the item. It is not. It is a position — a number that says where to look. The item is what you get when you use that position to index the array. Keeping those two apart in your head fixes a surprising number of bugs, because it makes it obvious that comparing i to a name or adding i to a total is nonsense.

The next lesson introduces a loop that hands you the item directly and never mentions positions at all. It exists precisely because most loops do not actually care where an item sits, only what it is.

A for header holds three things: where to start, when to keep going, and what to do after each pass. The condition is checked before every pass, including the first. A counting loop over an array starts at 0 and runs while the counter is less than the length. while takes only a condition and repeats until you make that condition false yourself. break leaves the loop; continue skips the rest of the current pass. The two bugs to expect are the extra pass at the end and the loop that never exits.