Get best of the week

What is the "clean code" in 2020?


“Clean code” and a clean cat

Don’t feed bread for Developers, let's argue about the cleanliness of the code: for example, Dan Abramov ’s post “Goodbye, Clean Code” made a fuss recently .

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 “to talk about it is useless”, 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 since 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 our three 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 hollow, 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!

UPD: , . , . - . . 13 , .


DotNext



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

“For me, clean code is a boring code, from the point of view of implementation. The only surprise in him is how much he is devoid of surprises. I have to feel, “Yes, I could write this”, 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


Visitors to DotNext do not need to introduce Andrey, but for the rest we’ll tell you that he is known for his work on the IDE Rider , BenchmarkDotNet library , vivid presentations and the book “Pro .NET Benchmarking”.

When we asked what he thought about clean code, Andrei referred to two of his old habraposts: “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. From reading a good listing, I get as much pleasure as 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 splendor 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 so that the project works well. But I still think that in any case, you should strive to write correctly, just that there should not be fanaticism. ”


Dylan Beatty


Habrachitateli can remember Dylan on his thoughtful and vivid report about work with legacy code: for Habr we did its decoding . And when we turned to Dylan about clean code, he wrote such a detailed and thoughtful text that publish it in at least a separate post:

“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, many developers who heard the words “clean code” but did not read the book. I even met them in a codrev: "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 the like.

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 is generally unclear 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 for concern. 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"- It's about architecture. This is about how you can dive into an unfamiliar code base and find 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 right 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 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. ” Generally they say 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 testing context, 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 turned out to be the most concise:

“Clean code is dumb, very understandable 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." Its definition turned out to be:

“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 Devshacht Podcast clearly stated his position:

“Robert“ Uncle ”Martin with his three main books (“ Clean Code ”,“ The Clean Coder ”and“ Clean Architecture ”), It seems to me that he 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 tripped 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 certainly 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. Namely, 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 is also familiar with the tests firsthand (unit, integration, E2E, B2B). Here is her text:

“Clean code is now a simple concept, but it is rather difficult to understand. It seems to me that clean code can be obtained by observing the following rules:

- 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, and also the rule “all decisions that may be taken later must be made 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 read easily 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 perspective”


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 this:

“A clean code is a 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 necessary 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 turned out to be:

“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.”

His conclusion sounds very friendly. But clean code is such a debatable topic that while one of you nods, someone else is probably on fire, feeling something like this:

  • « : „ , ”. , , : . , !»
  • « „ ”? „” , — , , „” — !»
  • “The words“ you can fill your bumps while the others look with bewilderment ”sound derogatory, as if only fools do so. But all the best and innovative appears when you fill up your cones and understand their reasons, and not just follow old books! ”


UPD March 12: Although Uncle Bob cannot fly to us, our St. Petersburg conferences ( for .NET developers , testers, and JavaScript developers ) are unlikely to dispute with clean code. On conference sites - always up-to-date versions of programs. Stay tuned and subscribe to our newsletters - once a week we will talk about the changes.

More articles:


All Articles