The 10 most common IGCSE pseudocode mistakes (from real student code)

Every time a student presses Run in this compiler and the program fails, we record which kind of mistake it was — never the code itself. We looked at the last 30 days of those errors from students writing Cambridge IGCSE (0478) and O Level (2210) pseudocode.

Most errors stop the program before it starts: the pseudocode is not written the way Cambridge writes it. The good news is that the same handful of slips cause most of them. Below they are ranked by the share of students (who hit any error) that made each one at least once. A student can appear in several.

1. Using a variable that was never declared — 37%

The most common mistake by a distance. Either the variable was never declared, or it was declared with one spelling and used with another. Total and Totl are different names, and so are Score and score in this compiler.

DECLARE Total : INTEGER
DECLARE Count : INTEGER
Total <- 0
FOR Count <- 1 TO 5
  Total <- Totl + Count
NEXT Count
OUTPUT Total

DECLARE Total : INTEGER
DECLARE Count : INTEGER
Total <- 0
FOR Count <- 1 TO 5
  Total <- Total + Count
NEXT Count
OUTPUT Total

15

Declare every variable at the top with its type, then copy the name from the DECLARE line rather than retyping it. Pick one capitalisation and keep it. See DECLARE and data types.

2. Leaving an IF or a loop open — 31%

Every block needs its own closing keyword: IF → ENDIF, FOR → NEXT with the counter, WHILE → ENDWHILE, REPEAT → UNTIL, CASE → ENDCASE. Forget one and the error often appears at the very end of the program, far from the real problem.

DECLARE Mark : INTEGER
INPUT Mark
IF Mark >= 50 THEN
  OUTPUT "Pass"
ELSE
  OUTPUT "Fail"

DECLARE Mark : INTEGER
INPUT Mark
IF Mark >= 50 THEN
  OUTPUT "Pass"
ELSE
  OUTPUT "Fail"
ENDIF

Write the closer the moment you write the opener, then fill in the middle. Indenting the body makes a missing ENDIF easy to spot — on paper as well as on screen.

3. Typing the wrong kind of value into INPUT — 24%

This one happens while the program runs. INPUT checks the answer against the variable's declared type, so typing sixteen or 16.5 into an INTEGER stops the program.

DECLARE Age : INTEGER
OUTPUT "How old are you?"
INPUT Age
OUTPUT "Next year you will be ", Age + 1

Choose the type for the data you expect: INTEGER for whole numbers, REAL for decimals, STRING for text, CHAR for one character, BOOLEAN for TRUE/FALSE. In the exam this is exactly what validation questions are about — see data types and the INTEGER vs REAL lesson.

4. Lines left half-written — 23%

An assignment with nothing after the arrow, a comparison with one side missing, a sum that stops at the operator. Usually the student meant to come back to it.

DECLARE Total : INTEGER
DECLARE Average : REAL
Total <- 240
Average <- Total /
OUTPUT Average

DECLARE Total : INTEGER
DECLARE Average : REAL
Total <- 240
Average <- Total / 3
OUTPUT Average

80

Every operator needs a value on both sides, and every condition needs something to compare: IF Mark > 50 THEN, not IF Mark > THEN.

5. The wrong quotes and symbols — 21%

Text copied from Word or Google Docs brings curly quotes (“like this”), which pseudocode does not accept. Strings go in straight double quotes; single quotes are only for one CHAR. A string that is never closed, or a stray ; or { from another language, causes the same kind of error.

DECLARE Greeting : STRING
Greeting <- 'Hello there'
OUTPUT Greeting;

DECLARE Greeting : STRING
DECLARE Initial : CHAR
Greeting <- "Hello there"
Initial <- 'H'
OUTPUT Greeting

Hello there

6. An ENDIF, NEXT or ELSE with nothing to close — 18%

The mirror image of mistake 2: a closing keyword with no matching opener. It usually comes from an extra ENDIF after a nested IF, or an ELSE placed after the ENDIF that already finished the block.

DECLARE Mark : INTEGER
INPUT Mark
IF Mark >= 50 THEN
  OUTPUT "Pass"
ENDIF
ELSE
  OUTPUT "Fail"
ENDIF

Count your openers and closers: each IF has exactly one ENDIF, and ELSE sits inside the block, before it. The fixed version is the one in mistake 2.

7. Closing keywords written the BASIC way — 13%

Other languages write END IF or ENDFOR, and flowcharts start with START and finish with STOP. Cambridge pseudocode does neither: closers are one word, a FOR loop closes with NEXT and its counter, and a program has no START/END wrapper — it simply begins at its first statement.

START
DECLARE i : INTEGER
FOR i <- 1 TO 3
  IF i = 2 THEN
    OUTPUT "two"
  END IF
ENDFOR
END

DECLARE i : INTEGER
FOR i <- 1 TO 3
  IF i = 2 THEN
    OUTPUT "two"
  ENDIF
NEXT i

two

8. Habits from Python and other languages — 11%

Students who already code in Python, JavaScript or Java carry the syntax over. The logic is usually right — only the words are wrong.

9. Array mistakes — 9%

Three versions of the same confusion: reading past the end of the array, using the whole array where one element is needed, and declaring it the wrong way. Cambridge arrays are declared with their bounds, and usually start at 1.

DECLARE Scores : ARRAY[1:3] OF INTEGER
DECLARE i : INTEGER
Scores[1] <- 12
Scores[2] <- 15
Scores[3] <- 9
FOR i <- 1 TO 4
  OUTPUT Scores[i]
NEXT i

DECLARE Scores : ARRAY[1:3] OF INTEGER
DECLARE i : INTEGER
Scores[1] <- 12
Scores[2] <- 15
Scores[3] <- 9
FOR i <- 1 TO 3
  OUTPUT Scores[i]
NEXT i

12
15
9

Make the loop run over exactly the bounds you declared, and always pick an element with an index: OUTPUT Scores[i], not OUTPUT Scores. See 1D arrays and the arrays lesson.

10. IF lines missing THEN, or with a broken condition — 8%

THEN belongs at the end of the IF line, and each side of AND / OR must be a complete comparison. Two versions come up again and again: leaving out the variable after OR, and writing a range with TO (which only CASE allows).

DECLARE Mark : INTEGER
INPUT Mark
IF Mark = 70 TO 79 THEN
  OUTPUT "Grade B"
ENDIF

DECLARE Mark : INTEGER
INPUT Mark
IF Mark >= 70 AND Mark <= 79 THEN
  OUTPUT "Grade B"
ENDIF

The same goes for IF Password = "cat" OR "dog": write IF Password = "cat" OR Password = "dog" THEN. See IF statements and the IF lesson.

Bonus: the one the compiler lets you get away with

Many students assign with =: Count = 0. This compiler runs it as a convenience, so it never shows up as an error above — but on the paper = means is equal to, and assignment is always <-. It costs marks precisely because nothing stops you. The assignment lesson drills it.

DECLARE Count : INTEGER
Count <- 0
IF Count = 0 THEN
  OUTPUT "Starting from zero"
ENDIF

Starting from zero

What to do next

• Paste your own program into the compiler — the error message names the mistake and shows the fix.
• Work through the Paper 2 Path: short lessons that check your code the way an examiner reads it. Levels 1–3 are free.
• Try exam-style practice questions with automatic marking.