Is it worth spending time on “flavorful” code design according to different Style Guides if the customer does not require it? Or is it all bad thoughts that appear from idleness, and the main thing is that the code works? Let’s find out from the experts.
First, we will talk to the Lead programmer
The answer directly depends on how and who the programmer works with.
If the programmer is faced with the task of writing an application or library for himself, or if in the future there are no plans to attract other people to work on the project, then you can really do all sorts of unspeakable things with your code that your heart desires. The golden rule for lone programmers is: “As long as I understand my code, I don’t need to do anything else.”
If a programmer works in a team (or is planning to do so in the nearest future), then it becomes necessary to document and test the source code, as well as to correctly name variables and follow the style guide. This is necessary in order to communicate your intentions to colleagues directly through the source code. Otherwise, the project will always face the threat of a large number of errors resulting from the influence of some parts of code on others – so called regressions. Teamwork also implies the use of non-trivial programming techniques – design patterns.
With their help, the code is broken down into the necessary structural elements that are documented and tested independently of each other. If all programmers who are working on the same project speak the same “language” of the application architecture, then everyone will be able to write such independent modules, and the probability of their “breakown” will tend to zero. Design patterns, unit tests, and code documentation are a kind of written agreement between programmers on how work is being done on a particular project. It helps colleagues to better help each other through code.
Anyway, using all of the above techniques to implement personal projects is a good way to discipline yourself, learn how to write code that is easy to maintain after many years of working on an application. For novice programmers, it’s also the best chance to get ready for the team work.
And the second expert is a Director of Information Solutions Department
Programmers get hit with this question quite often, and the main argument of opponents of “flavorful” code is that “time will be wasted”. And if the conversation turned to time, let’s look at the problem from the other point of view. Suppose someone has to modify the code written by another programmer (let’s imagine it will even be his own code, but a significant time has passed since it was written, and everything was forgotten). How quickly will you be able to deal with it when there are no comments in it, there are several actions on each line, and all variables are called “A”, “BB”, “CCC”? I’ll answer right away: sometimes it’s easier to write a new code than to unravel this “spaghetti”.
Thus, by formalizing and documenting the code, we significantly save the time of those who will continue to support and develop it.
