Chapter 8 — Programming II

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Functions and modules"]
  N2["8.2 Data structures"]
  N3["8.3 Reviewing for clarity and safety"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Functions and modules"]
  N2["8.2 Data structures"]
  N3["8.3 Reviewing for clarity and safety"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Functions and modules]
    |
    v
[8.2 Data structures]
    |
    v
[8.3 Reviewing for clarity and safety]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) organise code into functions and modules; (2) use data structures; (3) review code for clarity and safety.

8.1 Functions and modules

As programs grow, Sofia splits them into small functions, each doing one job: one parses a purchase record, one checks it, one applies it. Functions are grouped into modules by purpose. This makes code easier to read, test and review. A reviewer can check the checking function alone and be confident the rule is enforced in one place. Smart contracts benefit from the same discipline, because a rule scattered across many functions is easy to miss in one of them. Dr Asante notes that most contract weaknesses in the SWC registry arise from logic that is unclear rather than from exotic tricks.

8.2 Data structures

Sofia uses dictionaries to map member codes to balances, lists to keep transfers in order, and sets to track which shifts have already been rewarded. The set is important: before issuing a voucher she checks the shift is not already in the set, so the same shift cannot be rewarded twice. Choosing the right structure makes the rule simple. She compares this with a smart contract, where a mapping from shift identifiers to a boolean serves the same purpose. Duplicate reward is one of the simplest and most common ways that token systems drift from their intended totals.

8.3 Reviewing for clarity and safety

Sofia and a classmate swap code for review. They use a short checklist: are inputs validated, are edge cases tested, are names clear, does each function do one thing, and could the same action happen twice. Her classmate finds that Sofia's function rounds voucher amounts silently when given decimals. They agree it should refuse decimals instead. Review is a conversation, not a judgement, and both learn from it. The ConsenSys best practices encourage peer review before deployment. Sofia records each finding and its fix, building a habit of documenting decisions that she will keep throughout the degree.

Worked example

Sofia prevents double rewards with a set of rewarded shifts, and peer review changes silent rounding of decimals into refusal.

Synthetic case. The code and review are synthetic; the SWC registry and ConsenSys best practices are real sources.

Errors and limits

Silently rounding amounts hides input errors that should be refused and reported.

Exercises

• EX022 — Double reward guard. What prevents a shift being rewarded twice?
  Show marking criteria

  Rubric: 3 = a set of rewarded shifts checked before issuing;; 2 = a set;; 1 = vague;; 0 = none.
• EX023 — Review finding. What did the classmate find?
  Show marking criteria

  Rubric: 3 = silent rounding of decimal amounts;; 2 = rounding;; 1 = no tests;; 0 = none.
• EX024 — Checklist item. Name one checklist question.
  Show marking criteria

  Rubric: 3 = could the same action happen twice;; 2 = are inputs validated;; 1 = is it fast;; 0 = none.

Synthesis

Small functions, fitting data structures and peer review make token code safer.

Continue studying — chapter 08 of 40

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →