Dirty, clean, aspiring

Dirty

Let's think together - what is clean code, and what is dirty code? Or, as the Americans say - “hairy code”, i.e. hairy?

How does a clean code differ from a dirty one - or, as they say on these our Internet sites, from a “shit code”? And does he even need this clean code?


Let's first deal with the definitions.
')
It seems to me that it is simply impossible to give a clear definition of "clean" code. In part, this is like with beauty: you look at the picture, or there is a sculpture - and you see: yes, it is beautiful. Or, on the contrary, is ugly.

Yes, we learned to define general patterns, say, in persons who are considered beautiful. But are we ready to give a clear definition of beauty? I think no.

This analogy is not quite correct (like most analogies), but it roughly conveys the sensations that arise when working with code. It doesn't matter if it is a stranger, his own, written a couple of months ago and already firmly forgotten. The code is either like or not. He is either handsome, clean and pleasant - or hairy, ugly and smelly.

And, of course, each has its own criteria for "beauty code." Its, so to speak, taste.

But, nevertheless, there are some common points about which, if they argue, they are sluggish and conciliatory. Not about the essence, but about the frame.
Let's try to list them.

Easy to read and understand.	Confused, not obvious, difficult to understand.
Easy to change	Ossified in their internal relations; change is worth the incredible effort and sacrifice
Can be extended or embedded somewhere as a separate module.	Requires rewriting for expansion, wrappers for embedding
Amenable to automated testing	Can only be tested as a “black box”

Of course, you can start a dispute about the "readability" or "understandability" of the code. These are not formalized terms at all.

But they are also intuitively clear: if, for example, someone starts proving to others that they are used to writing the entire program in the form of one or two huge functions, “that do everything”, and solving the same tasks with at least splitting into a large number small procedures and functions for him is not clear - he hinted that it would be necessary to tighten the basics.

And it is desirable to thoroughly pick up the PLO and try to encapsulate logic in separate classes, so that you do not have to strain your brain by parsing huge code spoons on dozens of screens, or by intricate connections of procedures and functions that also (omg) operate with a bunch of global variables.

The situation is similar with the rest: of course, even among the 4 points listed there are mutually exclusive paragraphs (easily readable code will not always be easily changeable, ease of extensibility may conflict with test automation, etc.) - but in general the situation is clear.

In principle, guided by these points (strengthening or weakening each of them depending on the requirements of specific tasks), one can easily distinguish a dirty code from a clean one.

Although best of all, if it happens by itself, without too detailed analysis. When there is a “scent” that allows you to quickly understand that the code is dirty and stinks.

Clean

Now let's still try to figure out - why is it even needed, this clean code? And is it really bad dirty and hairy code?

Well, first you need to say: it depends.
There are times when writing “quick and dirty” is much more important than “long and clean”. Although it should be noted that “dirty” does not always mean “quickly.” It happens that exactly the opposite.


In general, let's try to consider more or less vital examples and try to understand in each case - when dirty coding is justified, and when absolutely unacceptable.

for example

On the server, something happens, the logs are written - but they are huge, and there is no one to read them. You need to write a small utility that reads the logs, pulls out some numerical data and presents them in a table. At the entrance - a log file, at the exit - a text with digits.

It is quite possible to write such a task as dirty as it pleases - if only the utilica worked, but the writing did not take much time. After all, we are solving one momentary problem here.
Solving the long-term problem is much better, by changing the error logging system (writing the same numerical data to the database, for example).

That is, ideally this utility is used once or twice, and then thrown out. The cleanliness of the code is completely unimportant here.

Another example

The server sometimes crashes, why - no one knows. The log analyzer made it possible to understand that a drop is caused by a large number of queries of the same type that come with quite specific parameter values, and this situation needs to be urgently reproduced.
You need to write a small utility that will exactly reproduce this behavior.

It would seem - all the same in one repeats the first example. However, the question arises here: since the testing process does not provide for the reproduction of such situations, will it not be necessary to further develop this utility as a testing tool? Will it become an independent application, which is used regularly?

If the answer is “yes” or even “possible”, then it is worth paying a little attention to the code being clear even to the developer himself in a month or two, and at the same time allowing him to somehow expand himself.
For example, add other request sequences, configure the server address and the number of requests, the values ​​of key parameters, etc.

This will slow down the development of the utility “here and now” only a bit - but when the question of reproducing a sequence of requests to the server again arises - the utility will be right there and will require minimal doping; and most importantly - the minimum time for remembering what is what.

Third example

Development of a software module for the main software product of a company that has been successfully developing on the market for several years.

It would seem that the module is isolated, interfaces for interaction with other modules are defined. "I twist-twirl, I want to write shit-code." But then there is a serious "BUT".

What will happen to this module in six months? Year? Would he require support? Changes? Functional extensions? Perhaps in the end will develop into a separate product?
If at least one question can be given at least the answer "probably" - then govnododit, alas, is strictly not recommended.

But this is not the whole list of questions. And who will work with this module in two or three years? The one who wrote it, or someone else?

If someone else - then in fact he will have to understand this code.
And if it is a bad, bad code, then either crying and chewing a cactus, cursing the creator, or throwing it all into the dustbin and rewriting it again, while receiving podzhopniki from the authorities for disrupting the deadlines.

If the developer himself will work with this code, then all the more so. Yes, after six months he will no longer remember: what, where and how it works! He will have to understand this code as if the code is completely alien. Isn't he his own enemy?

Fourth example

Development of an application (website, database with the simplest interface - anything) for an order in a short time for little money.

On the one hand - code and forget, you can write anything and anything, as long as it works.

On the other hand, what if this customer returns in a month and asks for something extra for adding or redoing something? We will cry, prick, but chew cactus? Refuse to order?

And what if he turns to another developer (company), receives a negative feedback on the quality of the project’s performance, and will never return to “evil gossip coders”, and even advise his friends?

I'm not talking about such things as the quality of karma and the memory of descendants.

Fifth example

Team development.

The most severe case of absolute non-govododirovaniya.
It's hard for me to even imagine any arguments in favor of making a conscious choice of bad code in the case of team development.

What can I say - one gobnoder can do more harm than an enemy agent behind enemy lines!
If a team does not isolate it, leaving them to write harmless, unconnected, absolutely left-handed utilities and mini-applications - then its productivity in the team will not be that zero - it will be negative!

The need to read, delve, correct, swearing - and eventually throw out and rewrite - not only takes more time than developing a good code on its own, it also spoils the overall atmosphere in the team and minus the moral of all developers who have to deal with a govnokod not your fault.

And testing? Escort? Expansion of functionality ??

I could write a couple of cheating paragraphs - but no. I can not.
The keyboard drops out of the weakened fingers at the thought of how much damage a command shit can do ...
This is terrible ... terrible ...

Aspiring

So, we approximately understand what a dirty code is and how it is bad. We still do not fully understand what clean code is, but we feel its necessity.
Why is it always there, this dirty code, why is it always present and spoils life for everyone - including its authors?

In my opinion, everything is extremely simple: to write pure code is an art, it is a superpower, which practically everyone can develop in themselves; but not everyone even thinks about the need for its development.

Not to mention getting an idea about this subject at a profile university or at specialized courses — only the very top of the “necessary” technologies, platforms and languages ​​are given there - few people pay special attention to improving their own pure coding skills.

Of course, over time, if the developer has developed a “nose for dirty code,” he inevitably begins to write all the cleaner and better.
He reads interesting articles at his leisure, he studies design patterns. But it happens that he does this because he is interested - and not because he is aware of the need to develop his skills in writing clean code.

And at the same time, ideally, he always feels that his code is still not good enough, that he is still far from perfect. And let his today's “govnokod” head and shoulders above the best that he wrote two or three years ago - there is still room to grow.

In this regard, I recall one interesting conversation with my colleague, who, like me, had the opportunity to conduct more than one interview with candidates for the position of developer - perhaps even more than interviews as such a candidate.

We talked about young programmers and what their qualities most of all testify to the potential of professional development.
In the end, it all came down to a few simple points, in order of importance:

1) A well-working head (so we always have logic problems)
2) A high level of self-criticism (therefore there are always tasks to write code and search for errors in it)
3) Interest in programming (less important, tasks are not determined in principle)

That is, it is clear that if the head works poorly, then you will not become a developer with all the desire and effort. However, even if it is golden and glows from rationality, this is far from a guarantee.

Often it happens that a young specialist, seeing how easy it is for him (especially - in comparison with most of his classmates, fellow students, just peers) begins to sincerely believe that only eggs are cooler.
And, although there are certainly some grounds for this, ChSV is so high that eventually one day it simply stops developing, believing that "I am already so clever, and who tries to challenge this is that dunduk."

And it is good, if at the same time he has a lively, keen interest in his work. If he continues to read articles and books "because it is interesting." Then he has a small chance not to harden, but to continue to develop.

And finally, it happens that a guy (or a girl — which is much less common, excuse me for this politically incorrect reality) is both clever and self-critical — rarely remains content with his code and generally thinks that he still needs to grow and grow. then the moment loses (well, if not completely) interest in the profession, begins to read less, experiment less.

Begins to perform tasks “strictly according to the specification” more often, preferably familiar tasks from familiar spheres. Pay less attention to new languages, platforms, concepts.

And it becomes quite a good, fit specialist. Often, even not very narrow, but relatively versatile. Quite respected.

But never reaches the top of its original potential.

And only in very rare cases, an intelligent, capable, extremely self-critical young man with burning eyes grows annually, hourly - and as a result becomes a star. It happens that it very quickly becomes a “local luminary” - but it does not freeze, it is not limited to this, but continues to grow, develop, improve.

Oh, how beautiful this picture - just want to brush away a non-existent tear! How beautiful he is, this young man, aspiring to infinity, with his spiritual impulse lifts the very heavens into which his all-pervading glance is aimed!

How happy are the people around him when they realize how great his path is, and in turn, at least take two or three steps next to him. Approaching at least on the hair to that beautiful infinity of possibilities, where he flies at all pairs!

How do you want to see more burning eyes, bright minds, turned into this infinity. How do you want at least a little help these atlanta on their way, even for a moment to support, push up, bring them closer to this unattainable and beautiful goal.

And stay down, with aching joy watching how they permeate space and time in their quest.

And to know that at least a little, at least a little bit - helped, supported, and did not stand aside, frozen in his ecstasy with his own importance, did not cast scornful looks - "phe ... young .."