|
Why Coding Standards?
Save your development team time by adopting a simple set of coding standards and ensuring their enforcement
by Nigel Cheshire
December 3, 2004
It's a fact of life: different people like to write code using different styles. Show me code written by 10 developers, and I'll show you 10 coding styles. So why try to develop and enforce coding standards? Because they'll save you time and money, and make you look smarter in the bargain.
The primary reason for adopting a set of coding standards is to make it easier for developers to read and understand each other's code. Although peer review is still relatively rare, almost everyone has to maintain—or, at least, step through—code written by someone else. A lot of time can be wasted just trying to decipher code that is not easy to understand. It's amazing how just a few, small differences in style can make reading code much slower.
According to Sun Microsystems, 80 percent of the lifetime cost of a piece of software goes to maintenance, and hardly any software is maintained for its whole life by its original author. Whether you believe statistics or not, when you think about it, it's common sense. To quote Bruce Eckel: "Code is read much more than it is written" (see Resources).
This issue is becoming key for many organizations. People at all levels in a development organization are focused like never before on costs; just look at all the brouhaha over offshoring and outsourcing. However, to get an effective grip on development costs, you need to understand the development process, and that means an understanding of the total cost of building and maintaining your software systems.
By the way, I may as well mention here that there's no reason that the adoption of coding standards should increase costs. All those fancy, multiline comments at the top of files with beautifully lined-up columns of asterisks are (or at least should be) a thing of the past. Coding standards should take care of easy decisions for you, leaving you free to concentrate on the real work. Overfussy styles should be replaced with more efficient equivalents.
Preempt Bugs
A second reason for adopting coding standards is to preempt bugs. Everyone knows that the cost of fixing a bug rises exponentially over time. Finding and fixing bugs in the development phase—and preferably even before unit testing—can save hours of time and resources later.
Another area—outside of cost—that gets a lot of attention when it comes to software bugs is safety. Common examples that have been cited include space shuttle missions, radiation therapy, and airplane applications. If faulty software can be reduced by preempting bugs and thereby reduce safety issues, coding standards are their own reward.
In addition to saving time and money, preempting bugs has another less-obvious (and sometimes, less-tangible) benefit: reputation. The reputation of your work as a developer or as part of a team is called into play each time you release a new application. You owe it to your teammates to develop code that doesn't cause them to pull their hair out should they have to work with it. The reputation of the product your company puts out is on the line; even more so if your application is part of a consumer good. You owe it to your end users, your customers, and your shareholders to ensure your product or application is the best it can be.
Back to top
|