Robust Programming
Robust Programming
Robust programming means writing code that handles unexpected inputs and errors gracefully without crashing. This topic covers defensive design, testing, and maintainability.
---
Defensive Design
Defensive design anticipates problems before they happen. The key techniques are:
Input Validation
Validation checks that data meets specific criteria before processing it. Common validation checks include:
| Check | Purpose | Example |
|---|---|---|
| Range check | Value within acceptable range | Age must be 0–150 |
| Type check | Correct data type | Price must be a number |
| Length check | Correct number of characters | Password must be 8–20 chars |
| Presence check | Field is not empty | Username cannot be blank |
| Format check | Matches expected pattern | Email must contain @ |
| Lookup check | Value exists in a list | Country must be in approved list |
Example (Python)
while True:
age = input("Enter your age: ")
if age.isdigit() and 0 <= int(age) <= 150:
age = int(age)
break
else:
print("Invalid. Enter a number between 0 and 150.")
Authentication
- Username and password — most common method
- Two-factor authentication (2FA) — adds a second verification step (e.g. text code)
- Access levels restrict what different users can do
Input Sanitisation
Sanitisation cleans input to prevent malicious data (e.g. removing <script> tags to prevent SQL injection and cross-site scripting).
---
Testing
Testing ensures the program works correctly. There are several types:
Types of Testing
| Type | Description | When Used |
|---|---|---|
| Iterative testing | Testing during development, after each module | Throughout development |
| Final/terminal testing | Testing the complete program | End of development |
| Unit testing | Testing individual components in isolation | During development |
| Integration testing | Testing components working together | After unit testing |
| Alpha testing | In-house testing by developers | Before release |
| Beta testing | Testing by a limited group of end users | Before full release |
Test Data
You must use three types of test data:
| Data Type | Purpose | Example (for age 0-150) |
|---|---|---|
| Normal | Typical valid input | 25, 67, 10 |
| Boundary | Edge of valid range | 0, 1, 149, 150 |
| Erroneous | Invalid input that should be rejected | -5, 200, "abc", "" |
Trace Tables
A trace table tracks the value of each variable as a program executes, line by line. They help you dry run code to find logic errors.
x = 1
WHILE x <= 4
x = x * 2
END WHILE
| Iteration | x | x <= 4? |
|---|---|---|
| Start | 1 | True |
| 1 | 2 | True |
| 2 | 4 | True |
| 3 | 8 | False — exit |
---
Types of Errors
| Error | Description | Example |
|---|---|---|
| Syntax error | Breaks language rules; won't run | Missing colon after if |
| Logic error | Runs but gives wrong results | Using + instead of - |
| Runtime error | Crashes during execution | Division by zero |
---
Maintainability
Writing code that others (or your future self) can understand and update:
- Comments — explain the purpose of code sections using
#in Python - Meaningful variable names —
totalScorenotx - Indentation — consistent indentation shows code structure
- Sub-programs — break code into reusable functions and procedures
- Constants — use named constants like
MAX_LIVES = 3instead of magic numbers - Modular design — separate program into logical modules
Example of Good vs Bad Practice
Bad:
x = 10
y = x * 1.2
Good:
VAT_RATE = 1.2 # Current UK VAT rate
price_before_vat = 10
price_after_vat = price_before_vat * VAT_RATE
---
Exam Tips
- Always give specific examples of validation — don't just say "check the input"
- When writing test plans, include all three types of test data (normal, boundary, erroneous) with expected outcomes
- Trace tables are frequently asked — practise following code line by line
- Remember the difference between validation (is it reasonable?) and verification (is it what the user intended?) — verification uses methods like double entry or screen confirmation