Img source: hongkiat.com
I recently read this wonderful article about the impossibility of having a perfect coding style guide that would please everybody. The author, Bill Sourour, a seasoned developer who has been programming professionally for decades, mentions that he himself had been involved in heated arguments by defending one coding style over the other. However, according to him, in the end it does not really matter that much, as long as it is a readable and maintainable code.
Bill mentions that one of the main reasons why people find it interesting to argue about the perfect coding style and not focus on things that really matter is because it is easier to get busy with trivialities rather than hard things. Programming is hard and involves a lot of mental effort and energy. As a result of this, our brains may unconsciously avoid the heavy stuff, and simply use these trivialities as excuses and hideouts from the things that make the difference.
Programmers are employed to solve real world problems, not to deal with coding styles. In most companies, you are not judged by the number of lines of code that you write, but by the value and the results that your company gets from your work. Solving problems, while using a coding style that your team has agreed upon, is something that you should be doing.
Programmers are humans that have their own unique tastes of code, and it is almost impossible to find a coding style that everyone would like. In the end you have to embrace the fact that you should develop the habit of getting used with something generally agreeable than being stubborn for using only the coding style of your choice, especially in projects were you are not a solo developer. In your own projects, you can choose and use whichever style guide that you like and probably nobody would yell at you.
I want to make myself clear: I do not intend to proclaim that style guides are not important and that having a clean, readable code is something that should be an issue that is totally neglected. In the end, as programmers, we primarily code in a programming language that is supposed to be read by other colleagues that we collaborate with in our projects. My emphasis, though, is that immersing yourself into arguments about the best places that brackets should be placed at is something that should not take a lot of your limited time.
Everybody can have a personal preference of one coding style over the other. When you are in a team with other developers, chances are that sometimes you may have to use coding style guides that you may not have at the top of your stack of choices that you wish to pick in your day-to-day work. To simplify your life as a software developer with the issue of coding style, Bill suggests to ask yourself these two questions:
- Is there tooling that will automatically apply the style rules to my code with little to no intervention from me?
- Are the tools and underlying styles actively maintained and/or used by reputable organizations?
If you answer to these questions is ‘Yes’, then Bill says that you are good to go.
To sum up, having a single and best coding style guide is arguably out of the range of possibilities. You should even not be considering such thing at all. Rather, you should be comfortable with coding style guides and make your code readable and maintainable in reasonable standards and invest the rest of your energy in solving problems. Avoid furious discussions about the best coding style. As Sayre’s Law puts it clearly, “In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”
