Chapter 3 — Programming foundations

Chapter 3 — Programming foundations

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Reading an export"]
  N2["3.2 Structuring the script"]
  N3["3.3 Reporting clearly"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX007"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Reading an export"]
  N2["3.2 Structuring the script"]
  N3["3.3 Reporting clearly"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Reading an export]
    |
    v
[3.2 Structuring the script]
    |
    v
[3.3 Reporting clearly]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) write a script to read an account export; (2) count accounts by clinic; (3) report clearly and repeatably.

3.1 Reading an export

The cloud directory can export users as a CSV file. Kai writes a short Python script, using only the standard library, that reads the file and counts accounts by clinic and status. He tests it on a small synthetic file whose answers he knows, including tricky rows such as a clinic name typed in capitals or an extra space. Testing first catches mistakes before they mislead anyone, and the script can be run identically every month to show how the numbers change over time.

3.2 Structuring the script

Kai's script has three parts: a function that reads the file, a function that counts, and a function that prints a report. Constants such as the file name are at the top. This structure makes it easy to change one part, such as adding a new count, without breaking others. Ruth reviews the script and suggests a header in the output showing the export date and script version, so anyone reading an old report knows exactly where its numbers came from.

3.3 Reporting clearly

The report lists each clinic with total, enabled and disabled accounts, and accounts with multi-factor authentication, each as a count and a percentage of its base. Kai sorts clinics alphabetically so reports from different months line up. He avoids unnecessary decimals and explains any unusual result in a note below the table. A clear, repeatable report lets the practice manager see at a glance where attention is needed without needing to understand the script that produced it. Consistency between months matters more than polish in any single report.

Worked example

Kai's script reports 97 accounts, 85 enabled and 12 disabled, with per-clinic counts; a test on synthetic data catches a capitalisation bug before first use.

Synthetic case. Exports, counts and bugs are synthetic.

Errors and limits

Running a new script on real data without testing it on known data risks reporting wrong numbers.

Exercises

• EX007 — Test first. Why test the script on a synthetic file first? Rubric: 3 = answers are known, so mistakes show;; 2 = known answers;; 1 = speed;; 0 = none.
• EX008 — Report header. What does Ruth suggest adding to the output? Rubric: 3 = export date and script version header;; 2 = header;; 1 = colour;; 0 = none.
• EX009 — Account totals. How many enabled and disabled accounts does the script report? Rubric: 3 = 85 enabled, 12 disabled of 97;; 2 = 85;; 1 = 97;; 0 = none.

Synthesis

Small, tested, well-structured scripts make account reporting repeatable and clear.

Continue studying — chapter 03 of 30

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →