Good Code Should Target Humans
Along with the machine.
I have been coding since my high school days. In these 2 decades, I evolved from writing code just for the machine to writing for fellow programmers and finally for both. I sometimes hope that I arrived at this realization earlier. But then again there are many things that come with experience and until and unless one does not face the repercussions of the earlier approach, one will not move towards a better approach.
Just for the machine
When I started coding, my main intention was to get the program to run. I would name the variables in the program as single alphabets from the English language e.g.
- int a;
- char c;
- float f;
Apart from the short variable names, the function and class names also didn’t have much meaning attached to them e.g.
Class A{};
int func1(int a){}
I was able to get along with this approach as after writing the code there was no need to revisit it. We normally would get different problems in every lab. If there was a project then also it won’t exceed more than a thousand lines of code.
“When the code is less our mind has the ability to keep track of the inherent meaning behind the various variables, functions, and classes used in the program”
This ability of the mind to be able to understand the code also stemmed from the fact that even if one needs to revisit the code, it won’t be after a substantial time gap. Most of the projects would get over in a matter of few months. On top of that, most of the projects would be done by an individual, thus removing the necessity for understanding other’s code.
Just for the fellow programmers
After the initial coding days, things changed when I joined the industry. There were many people involved in the project and the number of lines of code would exceed 100k.
“This meant I had to look at the code written by other people and also had to revisit the code after a gap of several months”
Thus, the foundation on which I was able to write the code just for the machine, got broken. I realized the following:
- Code should be beautiful: One now exposes his code to others and would like them to understand it without much problem. Apart from others, if one looks at his own code after few months, it seems new to him. Hence beautiful code with proper variable/function/class names should be written so that understanding the code is easier.
“Our mind has a certain limitation. It needs a reference to real-world objects to understand the code. Thus, writing a code that uses proper naming conventions is essential”
- Maintainability: In industry, it is important that a particular codebase exists for at least 5 years. In this timeframe, there will be a need to modify the code to incorporate new changes. Code that follows proper design principles would enable a programmer to make changes without breaking the existing system.
Also, our minds can focus on one thing at a time. Hence one should follow proper design principles where separation of concern is emphasized. It would help in understanding code in a better manner and would pave the way for maintainability.
Thus, I changed my focus from targeting code for machines to fellow programmers. This approach helped me a lot in traversing through the industry experience.
Both programmers and machine
After the initial days in the industry, I realized that I was not taking steps in writing code that would take advantage of the machine e.g. multiple cores, etc. I stayed with the simple programming model as it would be easily maintained and fellow programmers would also understand it easily. This in fact was a flawed approach.
“I realized that a good program should not underutilize resources”
I shifted my focus to understanding parallel programming, distributed systems, etc. These topics are not that simple to understand but should be used in the current programs to utilize the resources of the machine in a better manner and thus providing a better experience to the end-user.
This change in approach did not mean that I forego my earlier emphasis on fellow programmers. While implementing complex topics, one still needs to find a simple and elegant way of coding so that earlier advantages of maintainability and a better understanding of the code are possible.
Conclusion
Going through the various phases of coding, I realized that even the most complicated topics should be written in a manner so that we programmers can understand. Programmers are still the force behind the existence of various software and we should be able to have a grasp over what is going on. So even if we write complex programs that utilize the resources of the machine in a better manner, care should be taken that it is not elusive to the programmers themselves. Only then can the software survive the test of time.
