Developers like to discuss  the cleanliness of the code.

But at the same time, the very concept of “clean code” does not have a clear definition. The main book on this issue is “Clean Code”, where Robert “Uncle Bob” Martin immediately declares: “how many programmers, so many definitions”. However, from this he does not conclude “it is useless to talk about it”, but the conclusion “it is worth comparing different definitions”. Therefore, in the book he cited the views of several prominent programmers about what clean code is.

It became interesting to us: in 2020, the ideas of mankind about clean code remained the same, or did they somehow change from the release of the book? Do the opinions of different IT specialists differ: maybe backenders see everything from one angle, and testers from another?

In April, Uncle Bob will fly to St. Petersburg to speak at three of our conferences, and they are in just three different directions (about .NET development, about testing, and about JavaScript). Therefore, we asked several speakers of these conferences what clean code is for them to compare the opinions of industry experts in 2020.

And since the topic is holistic, for sure one of you will not agree with any of the opinions. In that case, come on to argue in the comments, this is also fun!

DotNext

John Skeet

John is the legend of Stack Overflow, author of C # in Depth, and one of the planet’s most famous programmers. He gave us this definition:

“For me, clean code is a boring code, from the point of view of implementation. The only surprise in it is how much it has no surprises. I have to feel “Yes, I could write that”, even if I really couldn’t – by how well designed it is.

When the abstraction is chosen correctly, the implementation is derived naturally. Ideally, this abstraction should also feel simple and obvious – although in fact, bringing it to such a state could take hours, weeks, months of reflection and experimentation.

The mentioned lack of surprises later carries over to use: when I write code using a well-designed API, my code also becomes obvious and boring. “

Andrey Akinshin

He is known for his work on the JetBrains Rider IDE, BenchmarkDotNet library, presentations and the book “Pro .NET Benchmarking”.

When we asked what he thought about clean code, Andrei referred to two of his old posts: “Perfect code and real projects” and “Comment or not comment”. And we have selected for you a couple of paragraphs from there, with which someone will probably want to argue:

“I love the perfect code. After all, this is not only the right approach to writing programs, but also a real art. I get as much pleasure from reading a good listing as from reading a good book. Designing the architecture of a large project is no easier than designing the architecture of a large building, and if it works well, the result is no less beautiful. Sometimes it fascinates me how gracefully interwoven design patterns in creating a perfect software system. I admire the attention to detail when absolutely every method is so simple and straightforward that it claims to be the classic example of perfect code.

But, alas, all this grandeur is broken up on harsh reality and real projects. If we are talking about a production project, users don’t care how beautiful your code is and how good the architecture is, they care that the project works well. But I still think that in any case, you should strive to write correctly, just that this should not be fanaticism. ”

Dylan Beatty

“It’s interesting for me that the concept of“ clean code ”has spread far beyond the circle of people who have read Robert Martin’s book. I talked with many developers who heard the words “clean code” but did not read the book. I even met them in codreview: “Everything is pretty good here, but can you clean it a little?” – and such a request can be annoyingly inaccurate if it is not obvious what “pure” means in this particular context.

In English there are words that are often found together – “clean”, “tidy”, “organised”, “neat” – and for me as a native speaker of English they all mean slightly different things. I think it is useful to consider some connotations of these words in relation to software development.

Imagine, for example, the kitchen of a restaurant. The word clean in this context will have very specific connotations. Everything is washed, sterilized, there is no threat of infection due to raw foods, and stuff.

But this does not automatically mean that everything is well organized here. If you ever tried to cook with a friend or in an apartment rented on Airbnb, you know how annoying it is when things are out of place. The dishwashing detergent is in the buffet in which you expect to see pots, and the garlic squeezer you do not know where. Yes, everything is clean – there is no threat that someone will like food cooked in this kitchen – but working in such conditions is annoying.

Now imagine a woodworking workshop. In this place, dirt can also cause problems, but here you do not have the same definition of “cleanliness” as in the kitchen. You can clean the chisel until it starts to sparkle, but you would still be unlikely to cut sausages with it. So the word “clean” can be very subjective.

But for me, words like “tidy” and “organised” work in contexts where “clean” doesn’t work very well. “Organized” means that someone has thought carefully about how to arrange the elements of a particular workplace, and “tidy” means that these elements are really in the places allotted to them. As the old saying goes, “everything has its place and everything is in its place.”

Perhaps in the case of the code, we should think of the words “clean”, “tidy” and “organised” as three different concepts. “Clean” means that you look at the components of the code base — methods, functions, interfaces — and you see no reason to worry. In naming adhere to conventions; names of variables and methods are written without errors; in details like indents and brackets adhere to a single style; wherever you look, you see evidence that at the basic level this is being run by people who are serious about business. This is the opposite of a “dirty code” – one where a lot of typos, curly braces and indentation are desirable in the names, inappropriate file names. These are the things that are magically fixed when you call the code cleanup tool in something like ReSharper.

Organized is about architecture. It’s about diving into an unfamiliar code base and finding things where you expect to see them. Interfaces and domain boundaries help, not interfere; the methods and variables named are not only correctly named from the point of view of the language, but also reflect the single language of the business with which you work.

And “tidy” is about respecting local conventions … a code base in which you can find the necessary things in their places, even if the specific organizational model is not very clear to you at that moment.

I think that when they talk about the struggle for “clean code,” this usually means all three of these things. But setting the goal to be completely “clean code”, especially when working with a complex legacy project, can be a pretty daunting prospect. Perhaps it would be useful for all of us to think a little deeper and figure out which of the components of the “clean code” will really benefit the project that we are currently working on. “

Heisenbug

This is a “testing conference not only for testers”: it is at the intersection of testing and development. Therefore, many of its speakers understand the specifics of both of these worlds at once.

Ivan Krutov and Anna Chernysheva

Ivan and Anna work in different companies, but something unites them: both know a lot about Selenium. We talked with them at the same time, so we got a joint definition:

Ivan: “For me, the simplest definition of clean code is code that is understandable without comment,“ self-documenting ”. Code that is littered with comments that try to explain what it does is not pure code. ”

Anna: “It seems to me: this is a code that you can quickly figure out, fix a bug, easily expand it, supplement it.”

Ivan: “You can also say that this is a“ code for which you are not ashamed. It is generally said that if you look at the code that you wrote six months ago and are not terrified, then you are not developing. It turns out that every year your code should become cleaner. ”

Sebastian Dashner

Sebastian is IBM’s Lead Java Developer Advocate, and can often be seen at Java conferences. But since he is flying to Heisenbug now, we asked him about clean code in the context of testing, and he replied:

“In my experience, code quality is important not only in the case of production code, but also for our tests. In tests, clean code, correct abstractions, and delegation are often neglected, which leads to a test code that you cannot support. When we refactor the production code and change its behavior, it becomes clear whether we have done a good job on modeling and implementing our tests. ”

Andrey Lushnikov

Andrey is working on a browser automation tool Playwright, which we recently wrote about. His definition was the most concise:

“Clean code – it is dumb, very clear code. And the dumber the better. ”

Alexandra Svatikova

Alexandra is an information security expert at Odnoklassniki, who “started in IT as a Java developer, but turned the wrong way.” Her definition was as follows:

“Pure code has three properties: another developer can easily read and understand it, minor improvements require a commensurate effort, and the effect of a particular change can be predicted.

In fact, this means that the code is structured, concise, follows generally accepted practices for the language it is written in, does not contain implicit dependencies or side effects and is covered by tests. ”

Holyjs

Andrey Melikhov

Andrei is known to many for the Devshakhta project. It is not surprising that a person who constantly formulates his thoughts in the “Devshaht-podcast” and clearly formulated his position:

“Robert“ Uncle ”Martin, in his three main books (“ Clean Code ”,“ The Clean Coder ”and“ Clean Architecture ”), it seems to me, is trying to answer questions for himself: who, what and how should write. One can argue about the correctness of some of his conclusions, but here is what is indisputable – these books are based on rich personal experience and common sense. And within the framework of this idea, I can say that for me a clean code is a code that would be written by a person who stumbled over a considerable number of pitfalls in his life and in this painful process learned to walk with a careful gait that allows them to be avoided.

You may not be comfortable with the style of this person, but if you follow him, you will definitely remain intact. You can take this style and recycle it, make it convenient for yourself. Or you can desperately dive into the river to fill your own cones, develop your own style, while the rest will look at you in disbelief, moving under the supervision of older comrades.

Pure code is code that is easy to read, easy to maintain, and easy to extend. It is these three aspects that lay a solid foundation for applications that have to live for years in the face of volatile external requirements. Exactly such applications we write in large companies “

Alexandra Kalinina

Alexandra is a member of the HolyJS program committee, she has extensive experience in programming – and although she is not with Heisenbug, she also knows the tests firsthand (unit, integration, E2E, B2B). Here is her text:

“Clean code is now a simple concept, but it’s pretty hard to understand. It seems to me that clean code can happen if the following rules are followed:

– each individual piece of code should be able to scale or grow / improve independently of other pieces, but at the same time retain the original idea / integration with other pieces (SOLID helps a lot, as well as the rule “all decisions that can be made later should be taken later ”).

– The code should be read as a fascinating book, with understandable typical names and designations. For example, if you decide to write a story, then it will most likely have a typical structure like an introduction, a plot, a climax and a denouement. Even if you are the only one working on a project, the code should be easily read by you after any time, regardless of the chosen architecture, language, frameworks.

– The code should have a clear structure. Those. the reason why this or that piece of code is in the project should be understood.

“Each line of code should be justified from a business point of view”

Nicolò Ribaudo

Nicolo, while still a student, became one of the key developers of the Babel compiler (we already asked him about this separately). His version turned out to be like this:

“Pure code is code that can be easily divided into small atomic components.

“Atom of code” is the smallest possible set of instructions that has independent meaning and does not depend unnecessarily on the surrounding context: the names of variables and operations are descriptive enough so that the reader does not need to allocate additional memory in their head to store their values ​​and possible modifications, as well as not it was required to look somewhere else in the code to understand what the result of this “atom” means. The smaller the atoms, the easier it is to understand what the code does.

The code can be clean regardless of the programming language or paradigm: atoms can be implemented as small objects, functions, or even as small pieces of code that are not syntactically isolated. “

Conclusion

Finally, when the opinions were collected, we showed them to Uncle Bob himself and asked if he wanted to say something. The answer was this:

“I fully support the commentators above. I would add only one thing that Michael Feathers once said: “A clean code always looks like it was written by a person who cares.”