Clean Code & SOLID
Clean code, naming, functions, errors, KISS / DRY / YAGNI, refactoring, Clean Architecture, and all five SOLID principles with practical examples.
16 lessons · about 0.9 hours
Start the first lesson →
- 01What Is Clean Code? Clean code is code that another person can read, understand and change safely. Here is why that matters more than clever code.
- 02Meaningful Names Names are the cheapest documentation you have. Learn simple rules for naming variables, functions and classes so code explains itself.
- 03Small Functions That Do One Thing Short, focused functions are easy to name, test and reuse. Learn how to spot a function doing too much and how to split it.
- 04Comments & Formatting Good code explains WHAT and HOW by itself; comments should explain WHY. Plus the formatting habits that make code easy to scan.
- 05Clean Error Handling Fail loudly, fail early, and never swallow errors. Learn how to handle errors so bugs are easy to find and users see helpful messages.
- 06KISS: Keep It Simple, Stupid The simplest solution that works is usually the best one. Learn to spot over-engineering and choose boring, obvious code.
- 07DRY: Don't Repeat Yourself Every piece of knowledge should live in one place. Learn when to remove duplication, and when duplication is actually fine.
- 08YAGNI: You Aren't Gonna Need It Don't build features or flexibility until you actually need them. Learn why guessing the future is expensive and how to stay ready for change anyway.
- 09Code Smells & Refactoring A code smell is a hint that something is wrong. Learn the 10 most common smells and the small, safe refactorings that fix each one.
- 10Clean Architecture Organise an application in layers so business rules don't depend on frameworks, databases or the web. Follow a real request through each layer.
- 11SOLID at a Glance Five design principles that keep object-oriented and modular code easy to extend, test and change. One picture and one sentence per letter.
- 12S — Single Responsibility Principle A class or module should have only one reason to change. Learn to find the hidden responsibilities in a class and split them apart.
- 13O — Open/Closed Principle Software should be open for extension but closed for modification. Add new features by plugging in new code instead of editing code that already works.
- 14L — Liskov Substitution Principle If code works with a parent type, it must also work with any child type, with no surprises. Learn the famous square-rectangle trap and how to avoid it.
- 15I — Interface Segregation Principle Don't force code to depend on methods it doesn't use. Split fat interfaces into small, focused ones that each client actually needs.
- 16D — Dependency Inversion Principle High-level business logic should depend on abstractions, not on concrete details like databases or email providers. The key to swappable, testable code.