ICDL Coding Principles (ICDL): The temperature logger that reports 13.3 °C on a 20 °C day

Mechanism: bad lines add 0 to the total but still count in the divisor. The average is dragged toward zero by entries that are not temperatures at all.

• ERR cannot convert to a number, so a typical pattern - try to convert, on failure use 0 - contributes 0 and increments the count.
• Blank lines do the same.
• 21,5 fails conversion on most parsers (a decimal comma is not accepted), so a genuine 21.5 °C reading also becomes a 0 - the worst case, because valid data is being thrown away silently.

Arithmetic check: 8 valid readings averaging 20 sum to 160. Count 4 rejected lines as 0 and divide by 12: 160 ÷ 12 = 13.3. That matches the reported figure exactly, which confirms the mechanism rather than merely suggesting it.

So the root cause is two faults, not one: invalid lines are being given a value of zero, and the denominator is 'number of lines' instead of 'number of usable readings'. Fixing only the parser would still leave a subtly wrong average.

Per line:

1. Strip surrounding whitespace.
2. If the line is now empty → skip it, increment rejected.
3. Normalise the decimal comma to a point. A defensible strict rule: replace , with . only when the line contains exactly one comma and no point, so a stray thousands separator is not silently misread. Document the rule - it is a decision, not a detail.
4. Attempt conversion to a number. On failure → skip, increment rejected, and keep the line with its line number in a small list so the teacher can see what was dropped.
5. On success → append the value to a list of accepted readings.

After the loop: if the list is empty, report 'no usable readings' and exit; otherwise average = sum ÷ length of the list. The divisor can now never include a rejected line.

'Never stops' is achieved because every conversion sits inside a guarded branch - no conversion is performed where its failure would end the run.

Remaining failure case: a file with zero usable readings would cause a division by zero if the average were computed unconditionally. That is the one path the loop cannot protect, so it needs its own explicit check before the division - and it is exactly the case that occurs when the sensor is unplugged and every line reads ERR.

Store accepted readings as a list of numbers; keep rejected as an integer plus a small list of the offending lines with their line numbers.

Why not just a running total: the total alone cannot give the denominator - you would need a separate counter AND the total, and the two can drift apart under later edits. It also cannot produce a median, cannot show the teacher the spread of a lesson's readings, and cannot be re-checked once the run has finished. A few hundred readings from a 45-minute lesson cost nothing to hold in memory, so there is no efficiency argument for discarding them.

Why keep the rejected lines, not just the count: '4 readings were unusable' tells the teacher nothing actionable; 'lines 12, 13, 40 used ERR; line 41 used a decimal comma' tells her the sensor was bumped or the wrong laptop was used. Silently excluding data without being able to show which data is the same failure mode as the original bug.

Precision note: the sensor reports to 0.1 °C, so summing integer tenths would make the total exact. For a class exercise floats are fine, but the choice should be deliberate rather than accidental.