Clean Code — 4 Rules of Simple Design
What if there were simple rules that could help you create a good design as you worked and help you gain insight into the structure and design of your code?
Kent Beck came up with four rules of Simple Design while he was developing ExtremeProgramming in the late 1990s. Until now, many developers feel that these rules are of significant help in creating simple yet well-designed software, and also helps in maintaining code to be clean. According to Kent, a design is “simple” when it follows these rules, in order of the importance:
- Passes the tests (It Works)
- Reveals intention
- No duplication
- Fewest elements
The rules are in priority order, so “passes the tests” takes priority over “reveals intention”.
Without further delay, let’s dig in each of every rule and talks about what they mean in the full extent:
1st Rule: Passes All Tests (It Works!)
First of all, of course, we need to make a working application to be delivered, that’s why it’s the number one priority. One of the many things that could make us sure that our app is working fine (and know exactly why it’s working) is to have tests for the particular code we wrote. Writing tests (comprehensive tests) actually could lead us to better designs. The more tests we write, the more we’ll continue to push towards things that are simpler to test, thus pushing us towards making our classes small and single purpose.
Once the tests are passed, we are empowered to keep our code clean. We do this by refactoring the code, and it’s better to do it frequently and incrementally after each few lines of code we add. After making a single feature work and pass all the tests, take time to review your code. Did others not understand what I actually write here? Am I just degrading it? If the answers are yes, then we clean it up and run our tests. The fact that we have these tests eliminates the fear that cleaning up the code will break it!
The next 3 rules could help you to check the quality of your code.
2nd Rule: Reveals Intention
When we are communicating with other people, we need to make sure other parties understand what we want to convey in our conversation. It’s also the same with code. As coders, we were working as a team in a project and there are lots of other coders that will see, touch, or even need to modify the existing code, and it’s very important for them to understand what you write in there.
To make our code reveals our intentions, we need to be expressive, and the most important way to be expressive is to try. Too often we get our code working and then move on to the next problem without giving a second thought to make that code easy to read. Place ourselves as other people that will become the next person to read our code. Care is a precious resource.
Some things that we can do to make our code more expressive are:
- Choose a good name that represents the things. Use predictable names so when other people read the class, function, or variable names, they don’t get a wrong idea or surprised when discovering the responsibilities.
- Keep your functions and classes small. It’s easier to name, write, and understand it.
- Challenge and commit yourself to write code so that it reads as documentation. Well-written unit tests are expressive and act as documentation by example. Someone that reads the tests should be able to get a quick understanding of what a class is all about.
Rule 3: No duplication
If you can re-use the code that already exists, why bother to write the same things again? Lines of code that look exactly alike, are duplication. This rule connected to Don’t Repeat Yourself (DRY) principle where we need to make sure that one method only has a single responsibility and not repeating. But, this rule is more about duplication of knowledge, not code duplication. Kent’s form of saying it is everything should be said once and only once.
Many programmers have observed that the exercise of eliminating duplication is a powerful way to drive out good designs.
The order of 2nd and 3rd rule might be slightly different in some places, in Robert C. Martin’s book: Clean Code book, it’s No duplication first and Reveals Intention the later, while in Martin Fowler article, it’s Reveals Intention first and No duplication the later.
From personal experience, I’m following the importance of Reveals Intention first and after that then I consider No duplication because it’s crucial for other people to be able to understand what I code first and often it’s connected to the duplication issue too to make my code more expressive. But some people also said that the order for these 2 rules doesn’t matter. When revealing intent, duplication in your code will be clearer and when duplication is reduced it will reveal it’s intent better.
Between these 2 rules, one thing that needs to be present: consistency. It should be understandable by another person that reads it and they can predict also implement the same rules given in the code addition.
Rule 4: Fewest Element
After we are doing the above rules: code expressiveness, removing the duplication, sometimes we can take it too far and this rule helps us to also check and be aware to maintain our code to have as few elements as possible.
These questions can be asked to yourself when you take some time to have a step back after writing some code:
- Do I have any dead code? Sometimes as we working through our system, we build things that aren’t final, and there are times that in the end, we don’t need it at all in the final product. If it’s happened, no question asked, just delete it.
- Have I extracted too far? Sometimes we can do over-extract while trying to better express our intent, for example when extracting methods for readability but we do it too far to the extent that every method has its own class.
Conclusions
These 4 rules are ordered by priority and complementing each other. When you get confused to some extent because the rules seem like conflicting with each other, going back again to the order of these rules.
Studying, understanding, and applying these rules can help us to be a better programmer that could write better code with quality. After all, we need experience and hands-on to fully understand and implements all these rules in our code. With experience, it’ll help us to understand and fully taste the benefits of implementing these 4 rules.
Finally, you guys can read Robert C. Martin’s book: Clean Code book as the original source, and another book: Understanding the Four Rules of Simple Design that gives real examples of implementing the rules at Game of Life.
This article is part of my collaborations with my co-worker about Clean Code:
PART 1 — Clean Code — 4 Rules Of Simple Design [Current ]
PART 2 — Clean Code — Object Calisthenics in Javascript
