Zuckerberg’s gray T-shirt and coding guidelines
You might wonder what Zuckerberg’s gray T-shirt has got to do with coding guidelines. I hope you will understand it soon. In this article I will try to explain why using coding guidelines is in everyone’s best interest, including the coder, the readers (usually other developers) and the management as well.
I am a bit obsessed when it comes to coding guidelines, even if I don’t like each and every one I have to use. Still, I try to follow these standards, not because someone just said so but in my opinion they can help us in many different ways.
Why guidelines are good for you if you are a reader?
A very important aspect is that, as a reader, you know what to expect. Guidelines set up expectations about how the code is going to look like. If you see certain names (class, function, variable names, etc.), you — as a reader of someone else’s code — know exactly which kind (e.g. static, local, parameter, etc.) to expect irrespective to the person who wrote that piece of code.
It is easier and faster to read code which follows a particular style, that the organization agreed on. This means that as a reader/reviewer you can focus on the whole code, you’re not just trying to put everything together line-by-line. In the end this can and, in most of the cases, will increase the quality. Also your satisfaction as a reader! I am pretty sure you feel happier when you understand something quickly.
When we talk about reading the code, let’s not forget, that a code is written only once (then of course it (d)evolves), but it will be read much more frequently by others. As H. Abelson and G. Sussman wrote: “Programs are meant to be read by humans and only incidentally for computers to execute.” [1]
So it is definitely worth spending time on making a piece of code readable. It will result in faster implementation of patches and bugfixes. But as I wrote, the quality will increase by using guidelines, so you will need less of those fixes.
Why guidelines are good for you if you are a developer?
Not only the reviewer will be more satisfied, but the author as well. Who likes to receive multiple pages of reviews about variable names, inconsistent coding style and lengthy functions?
If your code is easy to read and you’re consistent then your perception as a developer will be (even) better. Applying the guidelines, in other words doing the bare minimum in order to deliver clean code is a cheap but important investment in your career and reputation as a developer.
Although one’s style is not necessarily better than the others’, usually coding guidelines are written by developers having more experience than the average. There are many useful thoughts behind them which are worth to consider. If you read carefully the guidelines, you might find such pieces of finesse that you would not have found on your own for a while.
And of course you can and possibly will be the reader of your own code a few months later. Now think and ask yourself. How many times you cursed inside asking what the heck that code of yours, you wrote some months before, is doing? Was it clean code following the standards?
Why guidelines are good for you if you are a manager?
If you are a manager, I think you have been already convinced by what you read. More satisfied employees, better quality, shorter problem backlog? What else do you need? There is at least one more thing. Using the guidelines reduces the investment needed to get new developers on board. If a newcomer understands the code faster, (s)he will start providing valuable contributions earlier and in addition the new developer will also check in cleaner code as (s)he will follow the style of the others around.
Where is that T-shirt?
By now I told you why I am convinced that coding guidelines are good for readers, developers and useful for the management. But I still have not explained what does it have to do with the clothes of Zuckerberg or Obama.
The phenomenon is called decision fatigue in psychology. There are many famous leaders who wear almost the same clothes all the time, or eat the same meals everyday or just simply let someone else to decide when it doesn’t matter so much . We’re talking about people who make decisions everyday about the destiny of huge corporations or nations. How come they do not want to decide on their own outfit?
Making a decision takes energy and it is stressful. You cannot make decisions 24/7. Your brain needs some rest and you also have to focus on important issues. That’s why these people don’t decide on so insignificant matters.
That’s why you, as a developer, should not waste your time to find the correct order of parameters (order of input, output parameters for example) or the correct way of naming classes, etc. Of course, you shouldn’t just write random code, just like Obama won’t show up in a lousy pair of jeans when he visits the Buckingham Palace. No, you should write clean code in a particular style. The point is that you won’t have to make micro-decisions on naming-style, indentation-style because others already took those decision for you. Hence you can and should focus your energy, your decisive-power on design, data-structures and algorithms.
Summary
Good coding standards are beneficial for all involved parties, even though they are quite biased. They are optimised for the reader, not for the writer. As you have seen there is a reason behind. Code is read much more frequently than written. While a lack of standards can make your code unreadable, a piece of “code that is written using consistent guidelines is easier for other reviewers to understand and assimilate, improving the efficacy of the defect detection process” [2].
And don’t forget , “the best way to end up mediocre is via tiny compromises” [3]. Take your time and check in clean and consistent code that you are proud of.
References
[1] H. Abelson and G. Sussman: Structure and Interpretation of Computer Programs (1979, MIT Press)
[2] Wikipedia: Coding Conventions https://en.wikipedia.org/wiki/Coding_conventions
[3] Seth Godin: Raising the average (June 13, 2016) http://sethgodin.typepad.com/seths_blog/2016/06/raising-the-average.html
