ICDL Coding Principles (ICDL) common mistakes
ICDL Coding Principles · Understand the traps and how to avoid them.
When a program fails on a particular input, the candidate immediately rewrites whole blocks of code instead of first reading the error message and tracing the value of each variable through the failing step.
Under exam time pressure, rewriting feels faster than diagnosis, and candidates are uncomfortable reading stack traces or line numbers, so they change code they do not understand.
What to do instead
Before editing anything, write down the failing input, the expected output, the actual output, and the line where execution stops. Insert a print or trace of each variable at that point, fix one cause, and re-run. Only edit code you can explain line by line.
The candidate treats a loop condition as true/false at the wrong moment, producing off-by-one errors: one extra or one missing iteration, or an empty loop that never runs.
Candidates check the condition mentally only at the start, not after each increment, and they confuse 'while condition' with 'repeat until condition'.
What to do instead
For any loop, build a small trace table listing iteration number and each variable's value, including the value at the test. Check the boundary cases explicitly: zero iterations, exactly one iteration, and the final iteration.
The candidate mixes up assignment and comparison (using = where == is required, or vice versa), or confuses a single equals with equality inside a condition.
Mathematical notation treats = as equality, and candidates carry that habit into code without checking the language's rules.
What to do instead
Read every condition aloud as 'is equal to' and every assignment as 'becomes'. Scan each if/while condition separately and confirm it contains only comparison operators, never a bare assignment.
The candidate writes a solution that works for the sample input but never checks what happens with empty input, zero, a single element, negative numbers, or duplicate values.
Candidates test with the example provided and stop as soon as it passes, treating one successful run as proof of correctness.
What to do instead
After the sample passes, run a fixed checklist: empty, one item, two items, all-equal items, and the largest or smallest allowed value. Predict the output before running, and investigate any mismatch.
The candidate declares variables inside a block and then uses them outside it, or reuses one variable name for two different purposes, causing values to be unexpectedly overwritten or unavailable.
Candidates focus on the algorithm and ignore scope rules and naming, so they lose track of which value lives where.
What to do instead
Declare variables at the level where they are needed, initialise them before use, and give each a distinct descriptive name. Before submitting, list every variable and confirm it is declared, initialised, and still holds the intended value at each use.
The candidate converts a written problem into code before identifying the inputs, the required output, and the constraints, then solves a slightly different problem than the one asked.
Candidates pattern-match the question to a familiar exercise and skip the specification step, so hidden requirements such as ordering, rounding, or edge handling are missed.
What to do instead
Write three lines before coding: inputs, output, and constraints. Restate the task in one sentence and check it against the question. After coding, re-read the original wording and confirm each stated requirement is met.
The candidate writes nested conditions where the branches overlap or leave a gap, so some inputs match no branch or match two, and the wrong branch executes.
The cases are enumerated informally in the candidate's head rather than systematically, and the final else or default case is omitted.
What to do instead
List the cases as a table with non-overlapping ranges covering all possibilities, then write one branch per row. Always include a default branch, even if it only reports an unexpected value.
The candidate uses a data structure with the wrong access pattern, for example searching a list by value when a key lookup was needed, or treating a set as ordered.
Candidates pick the structure they used most recently rather than reasoning about the operations the solution requires.
What to do instead
Before choosing a structure, list the operations needed (lookup by key, ordered iteration, uniqueness, insertion at the front) and match them to the structure's guarantees. State in one sentence why the chosen structure fits.
The candidate leaves debugging output, commented-out experiments, or unused variables in the final answer, and does not check that the submitted program still runs cleanly.
Candidates treat submission as the end of work rather than a separate step, and assume the last successful run is the current state of the file.
What to do instead
Reserve the last few minutes for a clean submission pass: remove stray prints and dead code, rename unclear identifiers, run the program once more from a fresh start, and confirm the output format matches what was asked.
The candidate gives up on a problem after one failed approach and either leaves it blank or submits a partial attempt without stating the approach taken.
A single error is read as 'I cannot do this' rather than as information, and candidates underestimate how much credit a documented, partially working approach can earn.
What to do instead
When stuck, write the plan in comments first: inputs, steps, expected output. Implement the simplest correct version for the common case, verify it, then extend to edge cases. Submit the documented partial solution rather than nothing.