Dec 08, 2004

Coding Standards...

JavaPro has a piece on Why Coding Standards?, and I could not agree more. Each developer having their own style really makes maintenance and reading code much harder, and one problem that generally comes out of this is that branches are merged that reformat the code to the next developers tastes, and they happen to fix some bug in the middle of the code. These types of branches are the worst, because it makes it near impossible to compare the latest version of code to an older versions, since this stylistic factor overtakes the code, and you cannot make heads or tails of the changes.

Of equal annoyance are those developers who redo the code without understanding what the code actually does. Just earlier today I was reminded of this, as I was shown a piece of code that the person purported was mine. I looked at it, and I was rather surprised that it was mine as I quickly noticed a few obvious mistakes in the code. Looking through the history of this particular file, I was able to track down that the same developer who was confused of the code was actually the one who had rewritten the original code for simply stylistic reasons. This cannot be confused with refactoring, since the code was changed without maintaining the original contracts.

Coding standards can help to prevent bugs. I always use and highly recommend the standard that the article discusses from Sun, where statements are always surrounded by brackets, has prevented many bugs, and sometimes some confusion, simply by using this style. The next one regarding commenting is not one that I fully subscribe to though, since this generally produces code that has no comments what so ever, and such code may make sense today, but in the future, it can be hard to actually understand what the algorithm or function is suppose to do. This particular article hints that JavaDocs could be used instead of this, which could work nicely, since your methods should be short.

In the area of coding standards, getting very strict can make all the code look as it were developed by a single developer. To do this, though, some help of tools generally help. Tools like Borland's JBuilder has some reformatting and analysis capabilities that allows you to check your code against the standards while you are writting it, and this can be very useful.

Choosing the right standards, however, can be involved, and this is not covered by the article. For Java, many developers follow the Sun Coding Convension. For C++, this is hard one; from what I have seen, this may be C++ Coding Standards by Herb Sutter and Andre Alexandrescu, but there are really many topics and things to consider in such standards. Definitely some common knowledge, such as that of Effective Java, Effective C++, More Effective C++, Effective STL, Large Scale c++, and a variety of other books should be part of that coding standard.

Standards simply make better code, but you cannot apply such standards blindly; you need to understand why you are applying the standard, and more specifically, you need to know when you can break the rules. If you do not have a coding standard, it is probably time you have one.

Filed In