Conditions and loops

What is a condition, and what does a program lack without one?

A condition is a question with only two answers, yes or no, and the program takes one of two routes depending on which it gets. A program with no conditions is a list of instructions that always runs the same way from top to bottom; with the first condition, that list turns into something that reacts to a situation.

age = 17

if age >= 18:
    print("allowed")
else:
    print("denied")

The second line is the question, the third is the yes route, the fifth is the no route. The else is optional: leave it out and nothing happens when the answer is no, the program simply walks past the condition without a word. That silence matters later.

Two classic mistakes are waiting here. The first is confusing one equals sign with two: = means assign, == means compare. Python is kind about this and raises a syntax error if you put one equals sign inside a condition, but the languages this site is built with, PHP and JavaScript, raise nothing at all: if ($x = 5) assigns and is then always true, so your condition effectively does not exist and nobody says a word.

The second mistake is order, and it gets discussed far less. When you chain several conditions, the first one that is true wins and the rest are never even evaluated. So if you put the general condition above the specific one, the specific one never runs and you spend hours hunting a bug that is not there. The code is correct; only its order is wrong.

What is a loop, and what does every loop need?

A loop means: do this work more than once instead of once. Its value is in the count. Writing three lines for three files is no great feat, but those same three lines for thirty thousand files are only possible with a loop, and more importantly your code becomes independent of the number.

There are two main shapes. The first walks a collection and runs once per member:

names = ["ali", "sara", "reza"]

for name in names:
    print(name)

The second turns for as long as a condition holds, and how many times is not known in advance:

size = 4096
step = 0
units = ["B", "KB", "MB", "GB"]

while size >= 1024 and step < len(units) - 1:
    size = size / 1024
    step = step + 1

Every loop, whatever its shape, needs three things, and breaks if one is missing: something to walk or a condition to test, something that changes on each turn, and a way to end. In the second example size and step are the things that change; delete the line size = size / 1024 and the condition stays true forever.

One detail tutorials usually skip: the second half of that condition, step < len(units) - 1, has nothing to do with size. All it does is stop the loop walking off the end of the unit list. That loop lives in this site's own dashboard code, and that second half is the only thing standing between it and a real error.

Which loop goes where? A real count from this site's code

Most tutorials start with the counting loop, the one where a counter climbs from zero to some number. In real code it is the least used shape, and rather than guess we counted this site's theme.

Across 193 PHP files in the theme there are 560 collection loops, 21 counting loops and 13 conditional loops. So the shape you learn first accounts for under four percent of the loops in this codebase.

The reason is plain: you almost never want the member's number, you want the member. When you write "for each file in this folder", the file's index is no use to you, and keeping a counter is just one more place to be wrong. The 21 that remain are exactly where a number really is needed: drawing five review stars, building the columns of a table, walking backwards through the months of a chart.

We looked at those 13 conditional loops too, since the list was short. Seven are the main WordPress loop, which turns while posts remain. Three make a duplicate identifier unique: while this name has already been used, add a number to the end of it. The last three are places where the count genuinely is unknown: reading from a socket to the end of a response, converting bytes to a larger unit, and generating a username until it is not taken.

The rule that falls out of this count is more useful than any definition: if you know what you are walking over, write a collection loop. If you do not know when it ends, write a conditional loop. And if you genuinely need the number itself, then a counting loop, which in practice comes up rarely.

What does an endless loop look like on a real server?

An endless loop is a loop whose stopping condition never becomes false. It has two common shapes and both share one root: whatever the condition reads is not changed inside the body.

The first shape is forgetting that change altogether: the condition says turn while the counter is under ten, and nobody inside the body ever increases the counter. The second is changing it in the wrong direction, which is worse because the code looks full of movement: the counter goes down while the condition is waiting for it to go up.

Now the question no tutorial answers: what actually happens if this lands on a live site? The browser does not wait forever. On this server there is a setting called request_terminate_timeout and its value is 180 seconds. Any request still running after three minutes has its process killed.

And killed is the precise word here, not a metaphor. This is not a PHP error you can catch; the process is closed from outside. The consequence is that your ending code does not run: if the loop was halfway through writing a file, the file stays half written, and if it had taken a lock, the lock is not released. What the visitor sees is a generic server error page that says nothing about your loop.

So the skill to take away is this: you do not find an endless loop from an error message, because there is no error message. You find it from the clock. A page that always fails at almost exactly that same three minute mark is nearly always a loop, or a wait that never ends.

Conditions inside loops: break, continue and the off-by-one

The real home of these two ideas is side by side: a loop that makes one decision per member. The five line program in the first lesson of this track was exactly that, a loop over files with a condition on size.

Two words change the work here. break abandons the whole loop and leaves; continue abandons only this turn and moves to the next member. The first is for when you have found your answer, the second for when this member is of no use to you.

The surprise everyone meets once: if one loop sits inside another, break only breaks the inner one, not both. The program leaves the inner loop and quietly starts the next turn of the outer one. The code raises no objection and you believe you got out.

Another mistake has a name of its own, the off-by-one: the loop runs one time more or one time less than you expected. Its main source is that ranges are usually closed at the start and open at the end. In Python range(1, 10) gives you one through nine and not ten. That decision is not strange and it has a reason, but memorising it does not work; what works is writing one out and counting the output.

And the last case, the quietest of all: a loop over an empty collection. It runs zero times, raises no error and prints nothing. A program that did no work and made no complaint is always the first thing to check, not the last.

How do you read a loop you did not write?

This skill matters more today than writing loops, because code is read far more than it is written and a large part of that code was not written by you. Our method is four questions, and their order matters.

One: what is it walking over, and can that thing be empty? If it can, the loop runs zero times, and that is usually the case nobody tested.

Two: what changes on each turn? If your answer is nothing, either the loop is endless or the loop is pointless.

Three: what stops it, and could that never happen? Look for break statements here too, because an early exit is not always written at the top of the code.

Four: what is true after the last turn? What values do the variables built inside the loop hold afterwards, and is anyone relying on them?

Try those four on the unit conversion loop above: it walks no collection, so emptiness does not apply; two things change; the condition has two halves and one of them is only a guard; and after the last turn step holds the index of the correct unit, which is exactly what the next line uses. Four answers, and now you understand the loop without running it.