Coding Standards

"Coding Standards" is a phrase that I dread. Equally in the modern development world of source control and distributed teams it is important that it is standardised. In this post I will briefly explore both these statements.

When people have coding standards meetings it usually leads to arguments along the lines of "I think the brackets should be placed thus". People can argue till they are blue in the face about such things; I know I have in the past. Generally most people leave the meeting having aired their views but not changed their mind.

Given that we are all continuous integration people and we like good code we might also apply code quality tools, like Sonar, to our source control. I really like these tools as an indication of where code can be improved, where developers have been lazy and tracking trends over time, with (I might add) some cool animated charts. I think it would be a mistake to work on a project without such tools but sometimes the focus can become all about the numbers, writing tests to boost coverage and not about the code itself. Some of the more difficult indications, like Class Fan Out Complexity are hard to refactor away without considerable thought and effort. These seem to be the best indications of code smells, to much responsibility in one area but they simply get left in favour of tackling easy fixes to bring down the numbers.

Avoiding endless discussions on the topic works for me, if these rules are mandated by the powers that be that is fine, as long as everyone sticks to them. It usually does not take long to adjust to rules in place even if they are different from what you are used to; you could argue that it was part of being agile.

So it is infuriating when there are many developers working on the same code base and some follow a set of guidelines whereas others follow another set or not at all. This leads to merge issues, certainly SVN is not capable of distinguishing white space and other formatting changes. I think it also looks messy. I get accustomed to seeing code in a certain format, so I get good at pattern matching. When I then see code in a different format it immediately stands out. There may not be anything incorrect in that area but looking out of place it draws the attention unnecessarily and can distract you from looking for the real problem. Also, if you are measuring your code quality by code coverage tools it does not help if one set of people are continually adding to the burden of infractions you are trying to reduce.

With modern IDE's, formatting and save rules are easy to apply. If you are using maven you can even add plugins to format the code for you when you do a build. So if you like to view your code a certain way maven will format it as you build before you check in, assuming of course that you do that. I don't think that there is an excuse for allowing different code styles and rules given the problems that it causes.

So I don't like the endless discussion but I do like things to be standardised. I even don't mind if its done badly, but I want it done consistently.