Chapter 4 — Programming I
Lesson map
Lesson 04 published. Map, example, EX010.
flowchart TD
N0["Learning outcomes"]
N1["4.1 Reading data files"]
N2["4.2 Validation in code"]
N3["4.3 Handling errors"]
N4["4.4 Readable code"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX010"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["4.1 Reading data files"]
N2["4.2 Validation in code"]
N3["4.3 Handling errors"]
N4["4.4 Readable code"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]
[Learning outcomes]
|
v
[4.1 Reading data files]
|
v
[4.2 Validation in code]
|
v
[4.3 Handling errors]
|
v
[4.4 Readable code]
|
v
[Worked example] --> [Exercise EX010]
Learning outcomes
You will (1) write scripts that read and validate data files; (2) handle errors explicitly; (3) keep code readable for reviewers.
4.1 Reading data files
Kofi writes his first Python scripts using the standard library's csv module to read synthetic meter readings. Each row has a meter identifier, a timestamp, a reading and a unit. He learns to read files line by line, convert strings to numbers carefully and keep the original values for traceability. Prof. Varga requires synthetic data in every exercise, because student scripts often print data while debugging and should never expose real customer information. Each script also prints a count of rows read, rows accepted and rows rejected at the end.
4.2 Validation in code
Kofi adds checks: the meter identifier must match a pattern, the timestamp must parse, the reading must be a non-negative number and the unit must be cubic metres. Rows that fail are written to a rejects file with the reason, not silently dropped. He explains that silent dropping hides quality problems from data owners, while a rejects file gives them evidence to fix the source. Counting rejects by reason also shows which problems are most common. The commonest reason in the first run is a missing unit.
4.3 Handling errors
When a file is missing a column, Kofi's script stops with a clear message instead of guessing. When a single row is malformed, it records the problem and continues. He distinguishes errors that make the whole result untrustworthy from errors that affect only one record. Prof. Varga calls this fail loudly for structure, fail softly for content, and notes that governance depends on scripts that make problems visible rather than producing confident outputs from broken inputs. Both behaviours are tested with deliberately broken files.
4.4 Readable code
Kofi names variables clearly, writes a docstring explaining what each script reads and produces, and keeps functions short. A classmate reviews his code and finds an off-by-one error in timestamp handling, which Kofi fixes and covers with a test. He learns that code review is a quality control for the code that enforces data quality, and that readable code is easier to review, maintain and trust when other people depend on its output. The test now runs automatically whenever anyone changes the timestamp function in the script.
Worked example
Kofi reads meter files with csv, validates four fields, writes rejects with reasons, stops on structural errors and fixes a reviewer-found timestamp bug with a test.
Synthetic case. Files are synthetic.
Errors and limits
Validation rules in code drift from written rules; review both together.
Exercises
- EX010 — Rejects file. Why write a rejects file instead of dropping rows? Rubric: 3 = gives owners evidence to fix sources;; 2 = mentions evidence;; 1 = vague;; 0 = none.
- EX011 — Error policy. What does fail loudly for structure, softly for content mean? Rubric: 3 = stop on missing columns, record bad rows and continue;; 2 = both;; 1 = one;; 0 = none.
- EX012 — Review find. What did the code review find? Rubric: 3 = an off-by-one timestamp error;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 04 (chapter 04 of 50)
← Chapter 03 · Course chapter index · Chapter 05 →
Continue to the next authored lesson.