Loops: Repeating Work

Computers are not smart, they are fast. The loop is the construct that converts speed into usefulness: write a block once, run it a million times. Almost everything a program does at scale, summing a list, serving requests, redrawing a game frame, is a loop with a body.

A loop is a chore with a checklist. Wash a plate, look at the stack: plates left? Wash another. The moment the stack is empty, the check fails and you walk away. The check happens between plates, not during one, and you never decide in advance how many plates there will be. The condition decides when you are done.

The while loop: check, run, repeat

The purest loop is while: evaluate the condition, and if it is true, run the body, then jump back and evaluate it again. The subtle contract is that the body must eventually change something the condition reads. A counter climbs toward a limit, a list shrinks toward empty, a flag flips. When the condition finally comes back false, execution moves past the loop and never looks back.

Break that contract and you get an infinite loop: a program that is not crashed, not stuck, just perfectly obediently doing what it was told, forever. Every programmer writes one eventually. The teaching playground on this page has a hard step limit, so it is a safe place to get that mistake out of your system.

The for loop: a counter with the plumbing built in

Counting loops are so common that languages package the pattern: initialise a counter, test it, step it. That is all a for loop is. Lua's for i = 1, 5, Python's for i in range, and the classic three-part for in JavaScript, Go, Java, and PHP are the same machine with the parts arranged differently. The switcher below shows the identical summing loop in all eight languages.

Watch a loop breathe

Step through the program below and keep your eyes on two things: the counter climbing in the variables table, and execution jumping from the bottom of the body back up to the condition. The loop ends not when the body decides to stop, but when the check at the top fails.

Notice the accumulator pattern: a variable initialised before the loop, updated every pass, read after. Sums, counts, maximums, and built-up strings are all this one pattern. Notice also that i finishes at 6, not 5. The loop only stops because the counter went past the limit, and misjudging that edge by one is the most common bug in programming. It even has a name: the off-by-one error.

Fix a broken loop

This countdown is supposed to print 5 down to 1 and then liftoff. It currently does something much worse. Read it before you run it, predict the failure, then fix it. The step limit will catch you if your prediction was wrong.

Why loops matter beyond Level 1

Loops are where programs spend upwards of 90 percent of their running time, which makes them the pressure point for every topic later in this course. Obfuscation that bloats a hot loop makes the whole program feel slow, so good obfuscators treat loop bodies with care. A virtualized program, in Level 7, is itself one big loop, an interpreter fetching instruction after instruction, and its dispatch speed decides whether the protected program is usable at all.

For the expert lens: when an analyst reads unfamiliar code, loops are the first landmarks they mark out, because a loop implies data being processed, and the loop's condition names the data's shape. Flattened control flow, in Level 6, deliberately makes loop boundaries hard to spot by melting them into the same dispatch structure as everything else. And the run-and-dump attacks of Level 5 exploit loops from the other side: a decoding loop that runs at startup will happily hand over its output to anyone watching memory after it finishes.

A loop is a condition checked between passes of a body, and the body must push the state toward making that condition fail. Accumulators build results across passes, counters overshoot their limits by design, and the edge where a loop stops is where the bugs live.

Frequently asked questions