Clean Code and Design Principles Complete Guide
- Introduction to Clean Code and Software Design Principles
- Writing Meaningful Variable Names
- Designing Good Functions and Classes
- Software Design Principles - I (DRY, YAGNI, KISS, etc)
- Software Design Principles - II (Abstraction, Extensibility, Cohesion)
- Software Design Principles - III (SOLID Principles)
We can write clean code by following a set of guidelines known as Software Design Principles. Software Design Principles is a set of guidelines proven to work over the years.
I've listed down some of the most popular and useful design principles. You should try to enforce them in your code with every iteration.
This is the first part of the Software Design Principles Series.
Don't Repeat Yourself (DRY)
Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or can make the code change difficult. This can be fixed by doing code reuse (DRY Principle).
The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only one place.
Curly's Law - Do One Thing
Curly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.
Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean one thing in one circumstance and carry a different value from a different domain some other time. It should not mean two things at once. It should mean One Thing and should mean it all of the time.
Keep It Simple Stupid (KISS)
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
Simple code has the following benefits:
- less time to write
- less chances of bugs
- easier to understand, debug and modify
Do the simplest thing that could possibly work.
Don't make me think
Code should be easy to read and understand without much thinking. If it isn't then there is a prospect of simplification.
You Aren't Gonna Need It (YAGNI)
You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when you actually need them, never when you just foresee that you need them."
Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually, it'll turn out either:
- you don't need it after all, or
- what you actually need is quite different from what you foresaw needing earlier.
This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on.
There are two main reasons to practice YAGNI:
- You save time because you avoid writing code that you turn out not to need.
- Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.
Premature Optimization is the Root of All Evil
Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
- Donald Knuth
Boy-Scout Rule
Any time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it right there and then - or at least within a few minutes.
This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the code behind in a better state than you found it.
The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves us from that.
Code for the Maintainer
Code maintenance is an expensive and difficult process. Always code considering someone else as the maintainer and making changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
Principle of Least Astonishment
Principle of Least Astonishment states that a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users.
Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should be avoided as much as possible.
References:
---
Read next
