3 sins of a programmer: Hardcoding, Govnocoding and Shizokoding
There are 3 code problems you encounter in programming: Hardcode, Govnokod and Shizokod.
Let's talk about it.
Hardcode
This is a well-known problem, when a programmer, because of haste or laziness, writes code without variables. Perhaps the most frequent case is the site domain. It can vary from environment to environment and often delivers a lot of trouble. Everything is simple. In different platforms, this is solved in different ways. The main thing is to comply with the agreements and rules adopted within the framework of the platform.
Usually, problems of this class are quickly detected and easily treated.
Govnokod
This is a more difficult problem. Often subjective. Roughly speaking, this is a violation of the style of code adopted in the head, team or community.
There are different styles of code depending on the platform and even sometimes inside the platform:
This is from the world of php. In other communities, the situation is similar. This also includes stories about tab, tab after 2 spaces or tab after 4 spaces, etc.
This is where the problem of clean code arises ... for example, long functions of 3-4 pages, which is criticized. This is not always bad of course, but it is often possible to make such functions shorter, break into a series of short functions, each of which solves its own problem.
Usually these problems are easily treated through software and control of accepted standards in a particular team.
Aerobatics, when the developer can switch between different styles of code depending on the project.
It’s bad when a developer violates the code style adopted by the team or considers his favorite (often the only learned) code style to be the only correct one.
There are no correct code styles. There are approved styles in the team or common styles.
Also relatively simple problem and easily solved.
Schizocode
This is a less popular problem, but often the most expensive.
Shizokod - comes from the concept of schizophrenia. Marc from Wikipedia:
Schizophrenia (from the ancient Greek σχίζω to “split”, “split” + φρήν - “mind, thinking, thought”), previously lat. dementia praecox (“premature dementia”) or schizophrenia is an endogenous polymorphic mental disorder or a group of mental disorders associated with the breakdown of thinking processes and emotional reactions.
There are 2 important points: splitting and dementia. Which are the reasons for schizocode.
The ideal code is the one that is not written. Schizocoders are not familiar with this concept.
In short, shizokod, this is a code that violates the principle of Occam's razor.
Marc from Wikipedia:
“The razor (blade) of Okkam” is a methodological principle, named after the English Franciscan monk, the nominalist philosopher William Occam. In a simplified form, it says: “One should not multiply existing without need”
It is expressed in the fact that developers are beginning to complicate the code and architecture without good reason. Or the validity of the causes exists only in their imagination.
Imaginary problems are the root of bad software.
There are 2 main symptoms: the invention of bicycles on crutches and the reproduction of layers of abstraction.
The invention of bicycles on crutches
It means that because of the poor ability to learn, instead of finding the best solutions / methods within the framework of the platform and the existing architecture, developers are starting to reinvent bicycles / crutches.
Examples:
- Writing your CMS / ptm frameworks that existing ones have a fatal flaw
- Symfony blog. While the whole world uses WordPress for this.
- Online stores on Laravel, while there is WooCommerce (No. 1 in the world), Magento (also good), 1C-Bitrix (at worst, better than Laravel)
- I met the situation when the layout was on Bootstrap, but the developer decided to write his own styles for labels. What prevented the addition of the label class that already exists in Bootstrap?
- Unnecessary functions, methods and classes have no calculus that could have been avoided using ready-made libraries and methods in the platforms used.
Uncontrolled reproduction of layers of abstraction: extra classes, inheritance, methods
The attentive reader may have noticed the conflict with the govnokod. In one case, the problem is that the function or class is too long, and here the problem is that, on the contrary, excessive fragmentation of entities occurs.
Here it should be noted that this is one of the extremes, the boundary of which is not always easy to observe.
On the one hand, it’s bad to try to solve everything with a single function of 3 pages or a class that contains HTML and template mechanics and somewhere it is more advantageous to break the code into several functions / classes / components, each of which solves its own problem. This is one extreme.
On the other hand, it’s bad simple code to break into 5 classes in each of which there are 3-4 methods with 3-4 lines, with a lot of useless inheritance, when you can do one or two with minimal inheritance or even without inheritance if this can be avoided.
The consequences of unnecessary and bad abstractions
The multiplication of methods, classes, inheritances for no good reason - this is an extra code and the growth of layers of abstraction.
Everything has a price, as well as extra abstractions:
- training for new developers
- the more code, the more points of failure, the more errors
- complicated diagnosis and debugging code
Problem limbs thinking
The more layers of abstraction, inheritance, methods, the more fuel is needed for changes, improvements and diagnostics of problems.
And the working volume of fuel consumption is finite and often its lack entails very high development costs.
Each developer who made the diagnosis and change of schizocode rested on the lack of fuel consumption. But not everyone was aware of this.
Video, which explains what is thoughtful and gives a simple exercise for 1 minute, which allows you to recall the feeling of lack of thoughtfulness in a simple example:
Is it hitting the PLO, classes and inheritance?
By no means. However, there is some truth in this. In a functional style, it is easier to agree on a code, but there it is difficult to shizocode there. OOP, on the one hand, offers many advantages, but it also opens up scope for schizocode.
OOP, classes, and inheritance are neither bad nor good. These are tools. I personally use them.
However, I have a number of my own rules:
- I almost always write classes because of encapsulation, but often I have enough singletones, static methods and stateless
- Where there is a frequently used method - I write functions that are often just wrappers for methods of a particular class, but sometimes a function is just a function without a class and this is good where appropriate.
- Classes stateful - yes, but less often and again only where there are good reasons
- Inheritance is even rarer, and only where there are good reasons for it (I try to reduce the layers of abstraction and save my teamwork)
Summary
We talk a lot about hardcode and govnokode because they are understandable and easily tangible. But shizokod often goes unpunished, PTM that it is more difficult to identify and understand the amount of harm from it. And the amount of harm from it is possible more than you can imagine from a leap.
My manifesto is simple:
- it is better to learn the principle of Best of breed, before inventing another bicycle that is not needed by anyone on crutches
- let's write less shizokoda
- let's learn to observe the principle of Occam's razor and not complicate the code without a reason
- let's save our thinking and our team
Well, I will be glad to comment both in support of the manifesto and its criticism.