3 sins of the 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. It's simple. In different platforms, this is solved in different ways. The main thing is to comply with the agreements and rules adopted under 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:

• Symfony coding standards
• WordPress Coding Standards
• PSR - PHP Standards Recommendations

This is from the world of php. In other communities, the situation is similar. This also includes the 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 number of short functions, each of which solves its own problem.

Typically, these problems are easily treated through software and control of accepted standards in a particular team.

Aerobatics, when the developer can switch between different code styles depending on the project.

It’s bad when a developer breaks 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 generally accepted 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 Latin. 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 perfect code is the one that is not written. Schizocoders are not familiar with this concept.

In short, the schizocode is a code that violates the principle of Occam's razor.

Marc from Wikipedia:

The Ockam's Razor (Blade) is a methodological principle called the English Franciscan monk, the nominalist philosopher William Occam. In a simplified form, it reads: “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?
• There is no calculus for redundant functions, methods and classes that could have been avoided by using ready-made libraries and methods in the platforms used.

Uncontrolled reproduction of layers of abstraction: extra classes, inheritance, methods

The attentive reader might have noticed the conflict with the govnokod. In one case, the problem is that the function or class is too long, and the problem here 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, a simple code is simple to break into 5 classes in each of which 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 is an extra code and 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 fuel

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 point, 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.