Why It's Important to Let Your Code Explain What It Does

If there has to be a law in the development (coding) world which everyone should be familiar with, then it’s that “The more efficient your code is, the better”. But many developers take the wrong meaning from this idea of efficiency and try to go with the shortcut route. Well, they are not necessarily wrong, but not 100% right as well. In this blog, we will discuss why it is important to let your code explain.

The Meaning of Efficiency

Let’s be clear about one point, efficiency doesn’t always mean the shortest route possible. Depending on the context, the real meaning of efficiency can vary a lot. For example, in one way “Efficiency signifies a peak level of performance. It uses the least number of inputs to achieve the highest amount of output”. But in another way efficiency also means the highest degree of reliability, legibility, organization, and programming methodology used in the development process. We need to have a clear idea about the meaning of efficiency depending on the context. The first way, which focuses on the minimum number of inputs. It is definitely true in competitive coding or in assembly language. Because in these cases the speed of execution matters a lot. But in the production environment, the meaning of efficiency tends to lean on the second way which focuses more on reliability and legibility.

Production Environment

In a production environment, the goal of code efficiency is to reduce resource consumption and completion time as much as possible while keeping the code legibility & reliability the primary target. Now some may wonder, what do I mean by legibility. Legibility in development refers to the ease of understanding the code by other developers. It’s definitely the best idea to comment on your code properly. But if it becomes near impossible to extract the purpose of a piece of code without commenting then probably it’s not fit for the production environment. The purpose of commenting on a code is to clarify the logic. But without the comment, the code should at least define itself to a degree where the developer will be able to get a rough idea about its purpose. Now, I’m not saying that a junior developer will be able to understand the complexity of a code that comes in the expertise of a senior developer. That’s why companies have specific roles depending on the purpose. But if the code is not understandable even to a similar tier developer, then it needs to be modified.

Importance & Implementation

Now why this argument is so critical for a production environment? We need to keep in mind that a brand is bigger than a single person. Throughout the time a brand will cycle through different personnel for a specific role. That’s why it becomes crucial that the progress made by one person has to be understandable by the next person filling that role. Without a systematic approach, there will be a lot of repetition and the overall efficiency of a process will plummet.

So, what are the crucial points which we should keep in mind? Firstly, if a piece of code seems mysterious where the purpose and the output are unclear then it needs to be modified. The use of one-letter variables, irrelevant function names, unorganized files, and program structure is a danger zone for the production environment. Production level developers should have a mind set up that the code they are writing should have a minimum level of legibility. Comments should be considered as a best practice rather than a necessity. There can be some situations where a new piece of technology needs to be used. For example, a new package, a not so widely used function or a new syntax, etc. In those cases, comments will definitely be important. But the variable names, function names, placement of code, operators used, and so many other factors are there. It can at least give a rough idea about the purpose of that piece of code.

Conclusion

There is no strict rule which we have to follow to implement the concept of “Code speaking for itself”. Rather it’s a mindset to have while working on any project. If we try to avoid something which seems clever only to us. Then that will ultimately increase the reliability and legibility of a code. We want to increase efficiency in the production environment.

It can be done by reducing junk code, by keeping an organized program structure and file organization, by reducing repetition, and most importantly by keeping legibility a priority in every step.