ICDL Coding Principles (ICDL) common mistakes
ICDL Coding Principles · Understand the traps and how to avoid them.
Starting to type code immediately after reading the question, with no written plan of the steps or inputs/outputs.
Exam time pressure and the habit of treating coding as typing rather than designing; the candidate believes planning wastes time.
What to do instead
Before coding, spend 2–3 minutes writing pseudocode or a numbered algorithm and list the required inputs, processing steps and expected output; check the plan against the question before translating it into code.
Solving a different problem from the one asked - for example ignoring a stated constraint such as 'use a while loop', 'do not use built-in sort', or a required output format.
Skimming the prompt and pattern-matching to a familiar exercise instead of reading every requirement.
What to do instead
Underline command words and constraints in the question, restate the task in one sentence in your own words, and after writing the solution tick off each stated requirement.
Using a single equals sign in a condition (e.g. if x = 5) when a comparison was intended.
Mathematical notation uses '=' for equality, and many candidates read the condition as a statement of fact rather than a test.
What to do instead
Practise distinguishing assignment from comparison; when writing a condition, say aloud 'is x equal to 5?' and use the comparison operator (== or the language's equivalent).
Getting loop bounds wrong - running one iteration too many or too few, or looping from 0 when the task counts from 1.
Unclear mental model of whether the loop condition is checked before or after the body, and of whether the range end is inclusive.
What to do instead
Trace the first and last iteration by hand with a table of variable values; state explicitly whether the loop should execute N or N+1 times and test with a small N such as 3.
Using a variable as an accumulator or counter without initialising it first.
Assuming the language sets numeric variables to zero automatically, or forgetting the initialisation line when focus shifts to the loop.
What to do instead
Write the initialisation immediately before the loop (total = 0, count = 0) and keep a variable table showing each variable's value before, during and after the loop.
Changing a variable inside a function and expecting the caller's variable to change, or relying on a variable that is out of scope.
A mental model in which variables are shared globally rather than local to the block or function where they are declared.
What to do instead
Trace parameter passing explicitly: mark which variables are local, and return the updated value from the function and assign it at the call site.
Mixing data types - comparing a text input to a number, concatenating a number onto a string, or assuming integer division when decimal division occurs.
Inputs are often read as text, and the candidate assumes the value is already numeric or that division always behaves as in mathematics.
What to do instead
Convert inputs explicitly before use and check the type of each value in a trace table; test with a value such as '10' entered as text and with a non-whole division such as 7/2.
Declaring a program correct after testing only one typical case, without trying empty input, zero, negative numbers, maximum values or invalid data.
A single successful run creates false confidence; edge cases are not part of the candidate's normal test routine.
What to do instead
Build a small test table before testing, with columns for normal, boundary and invalid inputs, expected output and actual output, and run every row.
Debugging by randomly editing lines or deleting code without first reading the error message and locating the failing line.
Panic when an error appears, plus the belief that changing something quickly will make the message go away.
What to do instead
Read the error message and note the reported line number; reproduce the fault with the smallest input; state a hypothesis about the cause, change one thing, then rerun the same test.
Writing comments that merely repeat the code (e.g. 'increment i by 1' above i = i + 1) or leaving documentation unchanged after altering the program.
Documentation is treated as a final formality rather than part of the solution, so it is written from the code rather than from the purpose.
What to do instead
Comment the purpose and the reason for a step, not its literal translation, and update any affected comments, variable descriptions and test records at the same time as the code change.