The main characteristics of a quality code

How often do you get astonished when reading someone else’s code, and think “Lord, well, and porridge ...”. Most likely, quite often. And can you be sure that no one also thought when reading your code? In other words, how confident are you about the purity of your code? You can only be sure if you fully understand what clean code means.

It is difficult to give a precise definition of pure code, and, most likely, how many programmers - so many definitions. However, some principles are quite universal. I collected the nine most relevant and described below.

1. Bad code does too much; clean code is focused.

Each class, method and any other entity must remain undistorted. She must follow the principle of sole duty . In short, you can say this: if you think about the reasons for changing the class, you cannot think of more than one good reason.

But I would not limit the definition of classes. In his last article, Ralf Westphal introduced a broader definition of the principle of the sole duty:

A functional unit at a certain level of abstraction must be responsible for one aspect of the system requirements. A requirements aspect is a feature or property of a requirement that may change independently of other aspects.


If you want to learn more, I advise you to read his article .

2. The language in which you wrote the code should look like it was created to solve this problem.

It is not the language that makes the program simple, but the programmer who makes the language look simple.

(quote from Robert C. Martin)

This means that you do not need to use hacks, because of which the code and language usually look awkward. If you think that something can be done only with a hack or a patch, then this usually means that you didn’t spend enough time trying to find a good, clean solution.

3. No need for redundancy

The code must obey the rule DRY (Don't repeat yourself - do not repeat) . If this is so, then the modification of any element of the system does not require changing other, logically unrelated elements.

4. Read your code should be nice

When you read your code, there must be a feeling that you are reading "Harry Potter" (yes, I know, I’ve overdone it a bit). There must be a feeling that it was written so that any developer could read it easily, without spending hours trying to figure it out.

To do this, you should try to obey the principles of KISS (Keep It Simple, Stupid!) And YAGNI (You Ain't Gonna Need It - you will not need it). The KISS principle states that most systems work best if they are kept simple and not complex.

That is, simplicity should be the goal in design, and unnecessary complications should be avoided. YAGNI is a practice that motivates you to focus on the simplest things that allow your software to work.

5. Another developer can easily extend your code.

You do not write code for yourself, or even worse - for the compiler. You write code for other developers. Do not be selfish - think about people. Do not attempt other developers by giving out poorly maintained and poorly extensible code. In addition, in a few months this other developer may turn out to be yourself.

6. Need to minimize dependencies

The more dependencies, the harder it is to maintain and modify the code in the future. Always (in the case of .NET, - approx. Lane) you can help yourself to minimize dependencies with NDEPEND , for example. It checks for potential errors in dependencies in the code.

7. Less is better

The code should be minimal. Classes and modules should be short, ideally just a few lines of code. The code should be well divided (including inside the class). The better you share the code, the easier it is to read. This principle has a good effect on point 4 - it will be easier for other programmers to understand it.

8. Unit and Acceptance Tests Required

How can you tell if our code meets the requirements if you do not write tests? How can you maintain and expand it, without fear that everything will break? Code without tests is just not clean. If you want to learn more about the principles of unit testing, then I advise you to read a very good article Three Pillars of Unit Tests , written by one of my colleagues.

9. The code should be expressive.

The expressiveness of the code means that it uses names with meaning. These names must express intent. They should not be confusing. They must be distinguishable. Expressiveness documents the code and makes separate documentation less necessary. If you want to learn more about the topic of self-documented code, then I advise you to read this article .

So what is clean code?

In general, one last quality can be called the result of the foregoing:

Clean code is written for those who do not care.

quote by Michael Feathers.

It is written to those who treat the code as an art, and who pays attention to all the details.

The topic of clean code is very complex and goes beyond the framework described in this article. So, if you think that there are other characteristics of clean code, then please share them in the comments.