When It's Wrong

Every program you ever write will, at some point, do the wrong thing. Every one. The difference between someone who programs and someone who gets stuck isn't that the first makes no mistakes — it's that they know how to find them. This last unit is about that skill, and it ties off the thread we've pulled since Unit 1: the machine does exactly what you say, so when it's wrong, the job is to find where what you said and what you meant came apart — by looking, not guessing.

A bug you can see

Here is a program meant to double a number:

  10 INPUT "A number? "; n
  20 PRINT "Double it: "; n + 2

Run it and type 5. Double five is ten — so we expect 10:

7, not 10. Now — the computer did nothing wrong. It did exactly what line 20 says, faithfully. The bug is that line 20 doesn't say what we meant. So we observe (the answer is 7, we wanted 10), we localise (line 20 is the one that works out the number — read it), and we see it: n + 2. For 5, that's 7. We wrote add two when we meant times two. The output handed us the bug; reading the line named it.

That is the whole method, and it never changes: look at what it did, compare it to what you wanted, narrow down to the line responsible, and read that line for the gap. No guessing, no changing things at random to see what happens — looking.

The fix is small; finding it was the skill

Most bugs are like this: the fix is tiny, and all the work is in the finding. Which is why the finding is the thing worth being good at.

Read the report — it's information, not an insult

When a program doesn't just misbehave but stops, the Spectrum leaves a report, and it is the most honest help you'll get. You've seen several:

• 0 OK, 40:1 — finished cleanly at line 40.
• 2 Variable not found, 10:1 — at line 10, you used a box you never filled (Unit 5's name$ trap).
• 9 STOP statement, 60:1 — the program hit a STOP at line 60 (on purpose).

Each one names a problem and a line. That is a gift — it points straight at where to look. The programmers who stay stuck are the ones who see a report and freeze, as if they'd been told off. The ones who get unstuck read it: what does it say, and which line does it name? Half of debugging is just reading the message the machine already wrote you.

And the rare time it is the machine

Back in Unit 1: the machine was built by people, so a few genuine bugs are baked into the silicon and the ROMs. They're real — but they are rare, and almost never your problem. The discipline is to earn the right to blame the machine, not reach for it to dodge your own bug. You earn it by proof: cut the program down to the smallest piece that still shows the fault (it's astonishing how often that alone reveals it was yours); check it reproduces every time; and test it against a known-good reference — another machine, another tool, a documented result. If after all that the fault survives and the reference disagrees, then you may have found one of the rare real ones. Almost always, the cutting-down finds the bug was yours — which is exactly why suspecting your own code first is the habit that gets you unstuck fastest.

What you've learnt

• Every program misbehaves; finding out why is the skill that separates getting it done from getting stuck.
• The method never changes: observe the wrong result, localise the line, read it for the gap between meant and wrote. Look, don't guess.
• A report line is information — a problem and a line number. Read it; don't freeze.
• Suspect your own code first. Prove a machine bug (reduce, reproduce, compare) before you believe one — and you'll find it was almost always yours.

Where to go from here

That's the course. You now hold every idea a program is built from — sequence, output, memory, input, arithmetic, decisions, loops, named jobs, and how to find your way when one goes wrong. None of it was about BASIC; BASIC was just the first language to say these ideas out loud, and you saw each one in pseudocode precisely so you'd know it travels.

So that's what comes next: you choose a language to say them in properly, on a machine you fancy. The Spectrum's own BASIC is taught in full in Meet BASIC, which then builds real games with it — and it's only the first of a family. The same ideas wear the Commodore 64's BASIC, the Amiga's AMOS, and others besides: a different set of clothes each time, the same body underneath. Or, if you're headed for the metal, the path runs down through the number systems a machine counts in and on into assembly. Whichever you pick, you're not starting from nothing any more — you're starting from the ideas, which is the only place worth starting from.