Chapter 4 — Programming I

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Programs as precise rules"]
  N2["4.2 Records and data structures"]
  N3["4.3 Testing"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Programs as precise rules"]
  N2["4.2 Records and data structures"]
  N3["4.3 Testing"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Programs as precise rules]
    |
    v
[4.2 Records and data structures]
    |
    v
[4.3 Testing]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write clear standard-library programs; (2) model ledger records as data; (3) test simple functions.

4.1 Programs as precise rules

Jonas's first programming course uses Python with only the standard library. He writes small functions that model ledger operations: one that applies a transfer to a dictionary of balances, one that checks whether a transfer is valid and one that prints balances. Each function does one thing and has a name that says what. He learns that a program is a precise version of a rule, so ambiguity in the rule becomes a bug in the program. Writing the transfer rule from chapter two in code reveals that he had not decided what happens to zero-value transfers.

4.2 Records and data structures

Ledger records become tuples or small classes: operation, sender, receiver, amount and timestamp. Jonas stores balances in a dictionary keyed by account identifier and keeps a list of records in order. He chooses integers for amounts, never floating-point numbers, because floating-point arithmetic introduces rounding errors that could create or destroy small amounts of value. This decision mirrors guidance in the EEA EthTrust specification about rounding affecting value, and it is one of the first places where a programming choice becomes a security property.

4.3 Testing

For each function Jonas writes tests with known answers: a valid transfer, a transfer exceeding the balance, a zero transfer and a transfer to oneself. He runs them after every change. When he alters the transfer function to support fees, two tests fail, showing he forgot to deduct the fee from the sender. Testing early builds a habit he will need when contracts handle real value: in systems where deployed code is hard to change, finding errors before deployment is far cheaper than after.

Worked example

Jonas's ledger functions use integer amounts and pass four tests; adding fees breaks two tests and reveals a missing deduction.

Synthetic case. Code and tests are synthetic; EEA EthTrust is a real source.

Errors and limits

Using floating-point numbers for token amounts introduces rounding errors that can create or destroy value.

Exercises

• EX010 — Undecided rule. What rule had Jonas not decided? Rubric: 3 = zero-value transfers;; 2 = zero;; 1 = fees;; 0 = none.
• EX011 — Amount type. Why use integers for amounts? Rubric: 3 = avoid floating-point rounding errors;; 2 = rounding;; 1 = speed;; 0 = none.
• EX012 — Fee bug. What did failing tests reveal? Rubric: 3 = fee not deducted from sender;; 2 = missing deduction;; 1 = vague;; 0 = none.

Synthesis

Precise, tested functions with integer amounts form the base of trustworthy ledger code.

Continue studying — chapter 04 of 50

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →