Chapter 3 — Programming foundations
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Clear code"]
N2["3.2 Input validation"]
N3["3.3 Secrets"]
N4["3.4 Version control"]
N5["3.5 Tests"]
N6["3.6 Error messages"]
N7["Dependencies in code"]
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 code"]
N2["3.2 Input validation"]
N3["3.3 Secrets"]
N4["3.4 Version control"]
N5["3.5 Tests"]
N6["3.6 Error messages"]
N7["Dependencies in code"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Clear code]
|
v
[3.2 Input validation]
|
v
[3.3 Secrets]
|
v
[3.4 Version control]
|
v
[3.5 Tests]
|
v
[3.6 Error messages]
|
v
[Dependencies in code]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write small, clear functions; (2) validate input; (3) keep secrets out of code; (4) use version control and review.
3.1 Clear code
Diego writes small functions with one job each and names that say what they do. Clear code is easier to review, and reviewers catch more problems in short changes. In Diego's booking code this means one function checks the pet name, another checks the date and a third checks the time slot. When Aiko later finds the past-date bug, she finds it quickly because the date logic sits in one short function with an obvious name. Short functions also make the tests in this chapter easier to write, because each rule can be tested on its own.
3.2 Input validation
The booking form accepts a pet name, a date and a time slot. Each field is checked on the server against what is allowed: a name of 1–40 letters, spaces or hyphens; a date within the next 60 days; a slot from the clinic's list. OWASP ASVS input-validation requirements describe this allowlist approach. Each rule is checked again on the server even though the browser form shows hints, because a request can be sent without the form at all. Anything outside these rules is rejected before the booking reaches the database, so later code can rely on clean values.
3.3 Secrets
API keys for email and payments are read from environment variables set in the hosting platform, never written in code. A pre-commit check warns if anything key-like is added. Before this rule, a key pasted into a test file would have stayed in the repository history even after deletion. The hosting platform keeps Greenleaf's email and payment keys separate from other clients' keys. The pre-commit check is a safety net rather than the main control, since it only recognises key-like patterns it was written to find.
3.4 Version control
Every change is a commit with a message explaining why. Pull requests are reviewed by another developer before merging. For security work, this commit and review history is useful evidence as well. When the January advisory arrived, commit messages showed when upload-kit had been added to the Greenleaf project and by whom, and the pull request review shows that the version had not been questioned at the time. Diego writes messages that a future reader could use the same way, naming the library and the reason for every version change.
3.5 Tests
Each validation rule has tests for valid values, edge values and invalid values. For the pet-name rule, valid tests include a short name, edge tests include one letter and exactly forty, and invalid tests include forty-one characters and digits. For the date rule, the tests Diego adds after review reject yesterday and accept today. The tests run on every pull request, so a later change that loosens a rule fails before it reaches a client. A test that fails names the rule and the value, so the developer can see at once which change broke it.
3.6 Error messages
Errors tell the user which field is wrong without repeating unsafe input back into the page. On the Greenleaf form, a rejected pet name produces a message saying the name may contain only letters, spaces and hyphens, without echoing what was typed. Echoing raw input into the page is how harmful script can end up running in a visitor's browser. The message stays useful to the clinic's customers while giving nothing extra to someone probing the form. Server logs keep the full detail of each rejection, so developers can still investigate problems without exposing it to visitors.
Dependencies in code
When adding a library, Diego checks whether a few lines of his own code would do instead. Every library added is code someone else maintains, which Brightwave must then track and update for every client using it. Aiko's rule: add a library only when it saves real work and is actively maintained.
Commit hygiene
Each commit should contain one logical change, making review and rollback easier.
Worked example
In review, Aiko spots that Diego's date check accepts dates in the past. He adds the rule and two tests (yesterday rejected, today accepted).
Synthetic case. Code and reviews are synthetic.
Errors and limits
Validation reduces bad input but does not replace output encoding and parameterised queries.
Exercises
- EX007 — Name rule. What is the pet-name rule? Rubric: 3 = 1–40 letters, spaces or hyphens; 2 = partial; 1 = vague; 0 = none.
- EX008 — Secret storage. Where are API keys kept? Rubric: 3 = environment variables in hosting platform; 2 = partial; 1 = vague; 0 = none.
- EX009 — Review catch. What did Aiko catch? Rubric: 3 = past dates accepted; 2 = partial; 1 = vague; 0 = none.
Synthesis
Clear, validated, reviewed code with secrets kept out of the repository.
Continue studying — chapter 03 of 30
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →