The Secret to Clean Code

Discovering the main characteristics of Clean Code

What is Clean Code?

As Uncle Bob says in the Clean Code book:

There are probably as many definitions of Clean Code as there are programmers.

What defines Clean Code is both subjective and objective. Clean code can vary based on tech stack, domain, and company standards. In my daily work, I use Rust, C#, and JavaScript heavily. What's considered Clean Code in Rust might not be clean in C# or JavaScript.

However, Clean Code has some language-agnostic fundamentals. A common denominator that is shared across languages. Let’s explore the 7 things I believe describe Clean Code:

1. Clean Code solves the problem

You can create the most elegantly crafted software on the planet, but if doesn’t solve the business problem, it isn’t clean. Clean Code should solve the problem domain in the most efficient way possible. Software is all about making our customers happy. Clean Code is just a means to an end: enabling customer success.

2. Clean Code is like a well-written prose

Clean Code reads like well-written prose. It's easy to understand and enjoyable to read. Names are intention-revealing. Flow is simple. Clean Code tells a story. It has descriptive namings, proper formatting, and appropriate design patterns applied. These streamline the communication between developers, resulting in fluently readable code.

In terms of code structure, Clean Code is like a well-organized room; everything has its place, and it's easy to find what you need. When we look at the code structure, it should scream the domain. It should highlight the purpose of our app. It’s easy to navigate with clean domain separations. Clean Code has screaming architecture, expressing the problem it solves.

3. Clean Code is simple

The best design for software is the simplest one that works. The author doesn’t look smart. The code looks easy, but you can tell the author worked hard on it. Simple code is boring code.

Your code is not clean when there is nothing more to add. Your code is clean when nothing more to take away.

Clean Code requires simple tests as well. Tests should have similar quality standards as production code. You can only have Clean Code if you have clean tests. Tests should be treated as first-class citizens.

4. Clean Code is easy to improve

People say Clean Code is easy to change. Easiness to change is a poor metric. Clean Code isn’t about how easy to change it. It’s about how easy to improve it. The easiness of changing the code doesn’t clearly define how clean the code is. Changing the code is always easy. Improving the can be hard.

For example, consider deleting a line of code or renaming a variable. They are easy-to-do actions. Anyone can do that, even my nephew. The real question is whether these actions improve the system. Deleting a line is easy only if you have a quality test suite as a safety net. Renaming a variable is easy only if you have well-named software elements to reference. Clean Code makes improvements easier because the contexts support them. Your code is clean when it’s easy to improve.

5. Clean Code is tested

Clean Code is risk-free to change. The best way to reduce risk is to have quality automated tests. Tests are one of the most important parts of your app. They are codified knowledge of your code:

• They tell if the code works

• They show how the code works

• They reveal what the code is supposed to do

• And they document business knowledge

Having clean production code is irrelevant if you don’t have tests to support changes. As time passes, code tends to become more complex. The main role of our tests is to enable changes and aggressive refactoring. Writing Clean Code and maintaining it is only possible by practicing continuous refactoring.

6. Clean Code focuses on problem, not on solution

Clean Code tells a story of the problem it solves. If your namings contain a lot of technical jargon, then it’s probably focusing on HOW. Clean Code focuses on WHAT. Technical names such as DTOs, flags, and records are all related to specific solutions on the computer. They are code smells telling that your code focuses on a solution space. Instead, you should write code that speaks about the problem.

7. Code is clean if the entire team agrees

Clean Code isn’t defined by an individual's preferences. Instead, it's a collective effort where everyone's agreement is important. Clean Code is clean when everyone on the team thinks it's clean. They share a common understanding of what quality code means. This consensus promotes consistency. The team has a collective ownership of the code, where everyone follows the same coding standards. Clean Code is a team effort.

Conclusion

After all, Clean Code isn't an absolute concept; it's relative. However, there’s a universal practice to measure how clean your code is, regardless of your technology or team:

You just have to count the number of WTFs per minute.