Chapter 9 — Programming II

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Modules and tests"]
  N2["9.2 Handling bad input"]
  N3["9.3 Repeatable reports"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Modules and tests"]
  N2["9.2 Handling bad input"]
  N3["9.3 Repeatable reports"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]

[Learning outcomes]
    |
    v
[9.1 Modules and tests]
    |
    v
[9.2 Handling bad input]
    |
    v
[9.3 Repeatable reports]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) structure governance tools as tested modules; (2) handle bad input safely; (3) produce repeatable reports from code.

9.1 Modules and tests

In Programming II, Nadia restructures her policy checker into modules: one reads data, one applies rules and one writes reports. Each module has unit tests built with the standard library's test framework. She writes a test for every rule, including tricky cases such as a policy with two owners or a review date written in the wrong format. Separating reading from checking lets her reuse the same rules on other registers later, such as the list of suppliers, which also need owners and review dates at Ardwell.

9.2 Handling bad input

Real governance data are messy. Dates arrive in several formats, owners are written as names in some rows and as email addresses in others, and some rows are blank. Nadia learns to validate input explicitly and to report problems rather than silently skipping rows. A skipped row could hide a risk that nobody owns. Her program now lists every row it could not read, with the line number and reason, so data owners can correct the source. Prof. Brenner calls this failing loudly, which is a vital habit for compliance tooling.

9.3 Repeatable reports

Nadia makes her reports repeatable: the same input always produces the same output, with the date of the run, the version of the script and a summary of the input file printed at the top. If an auditor asks how a figure was produced, she can rerun the exact version against the archived input. She learns that repeatability turns a script from a personal convenience into organisational evidence, and that a report without its inputs and version cannot be checked by anyone else later.

Worked example

Nadia splits her checker into tested modules, reports unreadable rows loudly and stamps reports with run date, version and input summary.

Synthetic case. Registers and data are synthetic.

Errors and limits

Tests cover only cases someone imagined. Archived inputs need retention rules.

Exercises

• EX025 — Module split. Into which three modules did Nadia split her tool?
  Show marking criteria

  Rubric: 3 = reading, rule checking and reporting;; 2 = three;; 1 = vague;; 0 = none.
• EX026 — Skipped rows. Why is silently skipping unreadable rows dangerous?
  Show marking criteria

  Rubric: 3 = it could hide an unowned risk;; 2 = hidden risk;; 1 = vague;; 0 = none.
• EX027 — Report header. What does each report print at the top?
  Show marking criteria

  Rubric: 3 = run date, script version and input summary;; 2 = header;; 1 = vague;; 0 = none.

Synthesis

Tested modules, loud failures and repeatable reports make governance tools trustworthy.

Continue studying — chapter 09 of 50

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →