Chapter 3 — Programming I

Chapter 3 — Programming I

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Variables, conditions and loops"]
  N2["3.2 Testing with examples"]
  N3["3.3 Handling invalid input"]
  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 Variables, conditions and loops"]
  N2["3.2 Testing with examples"]
  N3["3.3 Handling invalid input"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Variables, conditions and loops]
    |
    v
[3.2 Testing with examples]
    |
    v
[3.3 Handling invalid input]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) write small programs with variables, conditions and loops; (2) test functions with examples; (3) handle invalid input safely.

3.1 Variables, conditions and loops

Sofia's first programs use Python's standard library only. She stores a member's voucher balance in a variable, uses a condition to decide whether a purchase is allowed, and uses a loop to apply a list of purchases in order. The program refuses any purchase larger than the balance and prints a clear message. Writing the rule in code forces her to decide what happens at the edge: a purchase exactly equal to the balance is allowed, leaving zero. Edge cases like this are where token software most often goes wrong, so she writes them down explicitly before coding anything else.

3.2 Testing with examples

Dr Asante asks the class to write tests before trusting any function. Sofia writes small assertions: a balance of 25 minus a purchase of 10 leaves 15; a purchase of 30 from 25 is refused; a purchase of zero is refused because it records nothing useful. She also tests a negative amount, which must be refused, since accepting it would silently increase a balance. Each test states one expected behaviour. When she later changes the function, rerunning the tests shows at once whether she broke a rule. Tests are cheap evidence that code does what its author believes it does.

3.3 Handling invalid input

Programs receive input they did not expect: text where a number should be, blank fields, or values far outside any normal range. Sofia's purchase function checks the type and range of every amount before using it and returns a clear error rather than crashing. She learns the principle of failing safely: when input is doubtful, the program should refuse the action and explain why, not guess. Smart contracts follow the same principle with require checks that revert a transaction. The ConsenSys smart contract best practices describe validating inputs early as a basic habit, and Sofia adopts it from her first week.

Worked example

Sofia's purchase function refuses amounts above the balance, zero and negatives, with four assertions proving each rule.

Synthetic case. Sofia's programs and balances are synthetic; ConsenSys best practices is a real source.

Errors and limits

Accepting a negative amount can silently increase a balance instead of reducing it.

Exercises

• EX007 — Exact-balance purchase. What happens when a purchase equals the balance? Rubric: 3 = allowed, leaving zero;; 2 = allowed;; 1 = refused;; 0 = none.
• EX008 — Negative amount risk. Why must a negative purchase be refused? Rubric: 3 = it would silently increase the balance;; 2 = wrong direction;; 1 = harmless;; 0 = none.
• EX009 — Failing safely. What does failing safely mean for doubtful input? Rubric: 3 = refuse the action and explain why;; 2 = refuse;; 1 = guess;; 0 = none.

Synthesis

Small programs with explicit edge cases and tests build habits that secure token code needs.

Continue studying — chapter 03 of 40

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