Although people think of programmers as nerds and geeks, they are actually a very varied group of people. In our own office you have mothers, geeks, jocks and even very arty people. Their programming styles vary just as much as their personalities and lifestyles. You get everything from the cowboy programmer that programs from the hip to the meticulous programmer who will write a comment for every line. This also leads to very different coding styles. Although it might not seem to be a problem initially, it can become a huge, time-consuming problem. For instance, when Mrs. Meticulous has to work with or on the cowboy’s code, the fact that he indented his code by only one space may make his code almost unreadable to her.
The compromise in the end is to have a coding standard: a set of rules that explains what the standard way of coding will be. It can specify everything from the amount of comments to where the period after a line of code must be placed. To say it is a compromise is accurate as no one person would be completely happy with all the rules as many of them might clash with their personal preference.
The advantages of a coding standard are obvious. The end result will be neat, uniform code that can easily and quickly be read by a programmer who is familiar with the standard. It will make it easier for new programmers to become acquainted with the code and for existing programmers to take over code that has been written by programmers that has left the company. Although a coding standard fixes a lot of problems, some caution has to be employed. Setting down the standard can be very time-consuming, as anyone who has sat through a two-hour meeting on where to put a “then” can attest. It might be valuable to get a neutral outsider to help negotiate the standard.
For more information please visit the QBCon home page.
