Everything so far has been about making code work. This lesson is about something just as important: making code that other people — including future you — can still understand six months later.
Code you write once and never touch again can be messy and it won't matter. Real programs get read, changed, and debugged far more often than they get written the first time. A little discipline now saves a lot of confusion later.
None of these require new syntax — they're just habits.
| Habit | Why it matters |
|---|---|
| Meaningful names over comments | A variable named daysUntilExpiry explains itself. A variable named d with a comment next to it can drift out of sync with the comment — the name never can. |
| Keep functions small | A function that does one clear thing is easy to test, reuse, and reason about. A function doing five things is really five functions wearing a trench coat. |
| Be consistent | Pick one naming style and one indentation style and stick to it throughout a project — consistency makes code predictable to read even in parts you've never seen before. |
| DRY — Don't Repeat Yourself | If the same logic is copy-pasted in three places, a bug fix has to happen in three places too, and it's easy to miss one. |
| YAGNI — You Aren't Gonna Need It | Don't build flexibility or features for a future that might never come — it adds complexity today for a maybe that may never happen. |
Compare these two versions of the same idea:
// Hard to follow
function calc(a, b, t) {
return t === 1 ? a + b : a - b;
}
// Clean
function combineAmounts(amountA, amountB, operation) {
return operation === 'add'
? amountA + amountB
: amountA - amountB;
}Same logic, same length — but the second version tells you what it does without needing a comment.
Object-oriented programming (OOP) is a way of organising code around "objects" — bundles of related data and the functions that work on that data — instead of writing one long list of steps. Most modern languages (JavaScript, Python, Java, C#) support it.
Think of a Car object: it has data (color, speed, fuel level) and behaviour (accelerate, brake, refuel) bundled together, instead of that data floating around loose and a pile of separate functions operating on it from a distance.
| Idea | What it means |
|---|---|
| Encapsulation | Bundling an object's data with the functions that operate on it, and hiding the internal details other code doesn't need to see. |
| Abstraction | Exposing only what's necessary to use something, hiding how it works underneath — you can drive a car without knowing how the engine is built. |
| Inheritance | A new object type can reuse and extend an existing one — a SportsCar can inherit everything a Car already has, and add its own extras. |
| Polymorphism | Different object types can respond to the same instruction in their own way — car.makeSound() and truck.makeSound() both exist, but do different things. |
class Car {
constructor(brand) {
this.brand = brand;
this.speed = 0;
}
accelerate() {
this.speed += 10;
}
}
class SportsCar extends Car { // inheritance
accelerate() { // polymorphism — its own version
this.speed += 25;
}
}
const civic = new Car('Honda');
const ferrari = new SportsCar('Ferrari');
civic.accelerate();
ferrari.accelerate();
console.log(civic.speed, ferrari.speed); // 10, 25You Don't Need to Use This Everywhere
You don't need to master OOP to be productive — plenty of real, working code is written without classes at all. But recognising these four words when they come up (in a job interview, in another language's documentation, in a codebase you join) is worth having early.
Clean code habits and basic OOP won't make a program run any differently — the computer doesn't care about your variable names. They make a difference to the next person reading the code, who is very often you.