How to write less code and get more sense

As the legendary writer Jules Verne rightly remarked: "A well-used minimum is quite sufficient." In our era, the concept of a well-used minimum applies to code. It’s sad, but true: in the modern world of code there is too much. To be more precise, there is too much unnecessary code, among which the useful code is simply suffocating.



Given the above, unnecessary code is evil by default. It deteriorates with time. It requires ongoing support. It contains bugs that you need to look for. When new functions appear, the old code has to be adapted to them. The more code you have, the more errors you can have in it. The more time verification or compilation takes, the longer the new employee will understand your system.



And on top of all this leapfrog, code is written by programmers. The more it is, the more programmers are required. With the increase in the number of programmers, the cost of communication between them also increases, which further contributes to the piggy bank costs of developing and maintaining the code.



For all these problems, there is one solution: write less code. This approach has a lot of advantages:

• Less code to develop = less development costs
• Less code in development = less maintenance costs
• Less code in development = less bugs
• Less code to develop = more effective testing

And most importantly: the less code you force people to read, the greater the likelihood that someone will read it at all.



Here are some ways you can cut down on code.

The YAGNI Principle (“You Don't Need It”)

The principle “You don’t need it” (it is often referred to as YAGNI - You Aint 'Gonna Need It) means the following extreme programming rule: “Realize this or that opportunity only when it is really needed, and not when you assume that she will be needed soon. ” Even if you are one hundred percent sure that this function can not be done in the future, do not start implementing it now.



There are two reasons for this practice:

• You save time by refusing to write code that is not currently needed.
• The quality of the code improves - you do not pollute it with fragments that are based on more or less correct guesses, and remain in the code base, even if these guesses are not confirmed.

The concept of YAGNI is quite reasonable no matter what project management methodology you adhere to. Good architecture requires a well-balanced balance of possibilities. Poor architecture consists of a bunch of sketched functions that generate a code base that you are tormented to support.



The basic rule here is: focus on what is clearly needed, and don’t think about what is likely to happen.

Do not write invulnerable code

An invulnerable code is an ideal code, a code that will work under any input data and any conditions. The idea to create something similar has its own appeal, especially for ambitious developers who perceive failure in some scenario as a personal insult. However, writing (or trying to write) invulnerable code is an empty idea, because everything in the world has its own limit, and code is no exception.



Trying to implement the ideal module, you will prescribe additional conditions, thereby adding complexity to the code base, which goes against the very purpose of the code. The module will become more extensive over time, eat up more resources and become a candidate for careless maintenance.



That is why, if you are aiming to write less code, you need to strive for the simplest possible implementation, from the category of "if only it worked."



The Extreme Programming Guide mentions two golden rules for writing simple code:

• First, implement the new functionality in the most primitive way that can only work. Do not erect breathtaking superstructures, do not refine yourself - just make sure that everything starts. Make sure that the code passes unit tests for the new functionality (and for the old one, as always).
• Then - and this is a critical part of the rule - refactor the system and simplify the code as much as possible for all the functions that are currently contained in the product. Follow the DRY principle and other principles that help make the system tidier.

Do not forget: we do not strive for the shortest path, but for the simplest result.



Accordingly, we begin by breaking the existing method into several parts. In this case, the test options will work without failures. Then we change (in the direction of simplification) one of the resulting small methods with an eye on the next test option and so on.



Remember that simplicity is at the heart of elegance. The ability to control and eliminate unnecessary complexity is masterly programming.

Don't make the code worse

This rule can be considered the Hippocratic oath for developers. Those involved in programming constantly hear tips not to cut corners and not to look for workarounds that can damage the code and lead to its degradation.



Software development procedures, like medical procedures, often involve gross interference and destructive actions. In addition, the tools and techniques that we use are often new and not tested (or not tested enough). On top of that, we do not have an analogue of the Medical Licensing Board or the Office of Product Control that governs the practices and development tools we choose. Thus, we sometimes expose our patient, that is, software, to procedures associated with unnecessary risks, and do not even fully understand what these risks are.



At times, in the process of fixing a problem, we do more harm than good. In his book "Perfect Code", which is part of the golden literature for programmers, Steve McConnell writes that if you are working not on the root of the problem, but on its symptom, you only worsen the situation - you deceive yourself, creating the illusion that the problem is solved .



But sometimes observing this rule can be very difficult. Sometimes outdated code is in such a state that it is practically impossible to properly implement new functionality without harming it. Therefore, in order to be more realistic, you need to rephrase the rule a little: from "Do not make the code worse" to "If you degrade the quality of the code, you must be aware of what you are doing."



Exactly. If you don’t see a way to implement the necessary features and not spoil the code, warn other team members before making changes. The bottom line is that in this case you degrade the quality of the code intentionally.



Of course, this will not make bad code better, but this way you will have time to think about the situation. Experience shows that people often do not reach the optimal solution simply because they are ready to accept the very first idea that comes to their mind. Note that we do not require that you ask for permission or help finding the best solution.



Another advantage of this method is that it reduces the likelihood of unpleasant surprises at bad times - the whole team knows what problems should be expected. Thanks to this, you can work in a team in the full sense of the word and deal with this situation in a timely manner.

Avoid excessive concurrency

Concurrency is a double-edged sword. It should be resorted to only if you can not do without it.



When the code is executed sequentially, it is easier to understand and look for errors. When using concurrency, operations are performed either simultaneously or in a distorted order. This specific implementation creates a lot of problems in identifying and eliminating errors. Obviously, it complicates the architecture and implementation of functions at once on several levels. Here are a few issues that poorly implemented concurrency can cause:

• Race condition: operations begin to occur unpredictably
• Mutual blocking: involved objects cross-block while waiting for simultaneous operations to complete
• Lack of resources: the operation stably does not gain access to the required resource that it expects

One of the most notorious disasters associated with software development was caused precisely by incorrectly written interdependent conditions. A programming error with Therac-25, a radiotherapy apparatus, led to the death of four people.



It should be noted that most modern programming languages ​​and frameworks provide special tools for debugging concurrency. But, ultimately, it all depends on the developer - it is he who decides when, where and how to apply them in order to achieve the best result.

Do not bump into hoarding

Pathological hoarding is a type of behavior characterized by the gathering of a large number of unnecessary things and the unwillingness to get rid of them; however, things can occupy most of the living space, which can lead to injuries and stress.



When the symptoms of accumulation appear among developers, they begin to cling to any piece of code, even if it is already outdated or teeming with bugs. Such developers never delete the code themselves and generally oppose this practice. If you tell them about this directly, get answers in the spirit: “He may someday be needed” or “Without this, I cannot perform operation X” and so on.



Has Plyushkin’s syndrome ever attacked you? Perhaps you abandoned the idea of ​​putting things in order because you understand that you simply don’t have enough time to figure out all this mess? If so, then you still suffer from hoarding and complete chaos reigns in your working life.



Saving is irrational. If it seems to you that the presence of some piece of code is justified, but you are not completely sure of it, mark it accordingly so that you can return to it later. So it will not fall out of your memory. As for the code, which does not fulfill a specific purpose and is not vital, it must be deleted and the point.



A good programmer works to improve the code day by day, and over time, the quality of the code is growing steadily. Outdated code written by a good programmer always stands out for its accuracy - professionals do not leave a mess after themselves; because the code is our reputation and it will be they who will judge us by it. As Robert Martin rightly said: "Truth can only be found in code."