Chapter 3 — Programming I
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Clear functions"]
N2["3.2 Errors"]
N3["3.3 Secrets do not belong in code"]
N4["3.4 Version control"]
N5["3.5 Pre-commit checks"]
N6["Code review"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Clear functions"]
N2["3.2 Errors"]
N3["3.3 Secrets do not belong in code"]
N4["3.4 Version control"]
N5["3.5 Pre-commit checks"]
N6["Code review"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Clear functions]
|
v
[3.2 Errors]
|
v
[3.3 Secrets do not belong in code]
|
v
[3.4 Version control]
|
v
[3.5 Pre-commit checks]
|
v
[Code review]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write readable functions with clear inputs and outputs; (2) handle errors safely; (3) avoid hard-coding secrets; (4) use version control well.
3.1 Clear functions
Lena writes order_total(items) that adds prices from the menu table, never from the browser, because prices sent by the browser can be changed. Business values come from trusted sources.
The browser sends only item identifiers and quantities. A test sends a request with an altered price and checks that the total still matches the menu table, which proves the rule rather than assuming it. The same principle applies to discounts and delivery fees: anything that affects money is computed on the server from data the society controls.
3.2 Errors
If an item is not on the menu, the function raises an error and the order is refused. Silent defaults, like treating unknown items as free, are dangerous.
Lena's function lists every case explicitly: a known item with a positive quantity is added, an unknown item raises an error, and a zero or negative quantity is refused. Each case has a test. Refusing early keeps bad data out of the database and the payment request, where it would be harder to spot and fix.
3.3 Secrets do not belong in code
The leaked token began as a hard-coded test value in a configuration file. Secrets belong in environment variables or a secrets manager, never in the repository, even for "test" keys, because repositories are copied and kept forever. OWASP Top 10:2021 A05 Security Misconfiguration and A07 Identification and Authentication Failures both relate to mishandled credentials.
The society now keeps example configuration files with placeholder values in the repository and the real values only in the hosting platform's secret store. New members are shown both during onboarding.
3.4 Version control
Each change is a commit with a clear message. A ".gitignore" file excludes local configuration files. Removing a secret in a later commit does not remove it from history; the secret must be revoked.
This is why the leaked token was revoked within hours rather than simply deleted. Lena's team also reviews the ignore file whenever a new tool is added, since new tools often create their own local configuration files that could hold credentials and would otherwise be committed by accident.
3.5 Pre-commit checks
A pre-commit hook scans changes for secret-like strings before they leave the developer's machine.
If the scan finds a match, the commit is stopped and the developer sees which line triggered it. False positives happen, for example with long random test identifiers, so the hook allows a marked exception that a reviewer must approve. A hook can be bypassed on one machine, so the same scan also runs on the shared repository, which is where the leaked token was caught. Together they give two chances to stop a secret.
Code review
Every change to CampusEats is reviewed by a second member of the society. Reviewers use a short checklist: are values from trusted sources, are errors handled, are any secrets or keys present, and are new dependencies justified? The checklist is short enough to use every time, which matters more than covering every possible issue.
Worked example
Lena reviews the leak: the token was in config/test.env, committed because .gitignore listed "test.env" in the wrong folder. The token was revoked within two hours. The society fixes .gitignore, adds the pre-commit hook and moves all keys to the hosting platform's secret settings.
Synthetic case. The leak and its handling are synthetic.
Errors and limits
Pre-commit hooks can be skipped; server-side scanning is also needed.
Exercises
- EX007 — Trusted prices. Why compute totals from the menu table? Rubric: 3 = browser values can be changed; 2 = partial; 1 = vague; 0 = none.
- EX008 — History lesson. Does deleting a secret in a later commit fix a leak? Rubric: 3 = no; history keeps it; revoke; 2 = partial; 1 = vague; 0 = none.
- EX009 — Leak cause. Why was the token committed? Rubric: 3 = .gitignore rule in wrong folder; 2 = partial; 1 = vague; 0 = none.
Synthesis
Write clear code, use trusted values and keep secrets out of repositories.
Continue studying — chapter 03 of 40
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →