I recently had a nice discussion with a fellow programmer about code style which triggered me to think on this topic and that in turn triggered this post where I hope to outline my thoughts on code style.
Code style is a set of rules used when writing source code. These rules do not usually make any difference to how the code runs but they make a huge difference in how the code looks like. In virtually all software teams I was part of, code style caused some arguments among programmers at one point or another. It is a controversial topic. I think there are two reasons for this.
First, programmers are very particular about how they do things, especially in writing programs. If you dare to ask a programmer to write his code in a certain style, you better have a really good reason for it.
Second, programmers tend to have strong opinions on topics that they understand inside out. If a topic is hard to understand, there has to be an initial upfront investment to understand the topic in order to have an opinion about it. The investment has to be even higher if you want to have a strong opinion because you’ll need to defend your strong opinion against fellow programmers and that requires that you really know what you’re talking about. Code style is both trivial to understand and requires minimal investment in understanding the code style rules. Therefore, programmers tend to have strong opinions about it.
The first camp in code style thinks that code style is extremely important in programming. Code style in programming is like punctuation in writing. No serious writer even considers writing without punctuation and as such, no serious programmer should consider writing code without a common style. According to this camp, the team has to agree on every little detail in code style and the whole team has to adhere to those rules. It’s a sin to not adhere to code style. You write code not for yourself but for other programmers to read and understand and you have a responsibility to make sure your code is understandable and adheres to some common style.
The second camp in code style thinks that code style is utterly useless and sometimes even harmful in programming. They think that it’s hard to find a common code style that all programmers agree and it’s even harder to make programmers adhere to it. At the end of the day, code style has no effect on how a program runs, so spending so much time and effort on something that does not make a difference in reality is useless. Instead, time could be better spent with test coverage or design improvements which do have significant impact on how a program runs. Code style not only causes friction in a team, it also takes valuable time away from useful activities like extending test coverage.
I think both camps have valid points and I can relate to both. However, I don’t think that either camp is totally right. The right attitude about code style lies somewhere in the middle. The first camp is right that we write code for others to read and I agree that we need to pay attention to how we write code. It’s just selfish to have a “my-way or highway” type attitude with code. There’s something more important about code style though. If a team agrees on a common set of rules regarding code style and actually sticks to those rules, it shows that the team is indeed a team that can act like a unit. It shows that people have no egos and the code generated is not considered as yours or mine but rather considered as team’s code both for the team members and to the outside world. This is an important goal to strive for a team and since code style helps in achieving that unity, it should not be dismissed so easily.
On the other hand, the second camp is right that code style should not come at the expense of test coverage or other activities involved in software development. I think this could happen if the team suddenly decides to implement code styles on existing/legacy code. Instead of fixing the code and making it better for existing customers, the team spends the time to make the code look pretty. That’s silly. Similarly, in dysfunctional teams, agreeing on a common code style is a daunting task and it could suck a lot of time and energy out of the team. All of this can be avoided by having a strong figure in the team leading the team to agree on a common code style upfront, however little the commonality might be, and then making sure everyone sticks to these rules throughout the project. Sure that’s some initial investment but once the initial agreement is done and habits start setting in, programmers don’t really have to think about code style, it just happens.
To sum up, I believe that code style is important and all its pros and cons should be considered before adapting or completely abandoning it.