Most Read This Week
Why Coding Standards?
Why Coding Standards?
By: Nigel Cheshire
Jun. 28, 2006 03:00 PM
Show me code written by ten developers and I'll show you ten different coding styles. So why try to develop and enforce coding standards? Who cares what a program looks like as long as it works?
The primary reason for adopting coding standards is to make it easier for developers to read and understand each other's code. Although peer reviews are relatively new, most developers maintain.or at least step through.someone else's code. A huge amount of development effort is wasted reading undecipherable code. It is amazing how a few style changes can make code difficult to read.
Armed with coding standards, development teams can improve the quality of their software, making it easier to maintain and they can pre-empt bugs before they reach end-users.
This is becoming a key issue for many Java development organizations, where people at all levels are focused like never before on costs . . . look at the attention given to out sourcing and off shoring. To get an effective grip on development costs, you need to better understand the development process, especially as it relates to the total cost of building and maintaining software systems.
In a rush to meet an application development deadline, it is easy to neglect style and readability. Things like naming conventions and code consistency are ignored when developers are under pressure to perform. We are learning, however, that maintaining quality is the key to successfully meeting deadlines; therefore, development managers must be especially vigilant during these critical phases of a project.
For many development organizations, quality assessments are a thorny subject. While development managers are struggling to keep projects on track, how do they gain visibility into their team's performance as it relates to code quality, without involving them in costly and inefficient code reviews?
Code commenting is a common area where standards can improve readability. At Teamstudio, we believe in keeping code comments to a minimum. For those of us who learned software development more than a few years ago, this sounds like heresy. This new approach to commenting, ."The code is the documentation" .comes from hard-won experience with trying to maintain heavily commented code, where the comments quickly become out of sync as the code evolves.
Bad or out of date comments are worse than useless: they can cause a great deal of wasted time and frustration. To quote Sun Microsystems, "When you feel compelled to add a comment, consider rewriting the code to make it clearer." Javadoc is a great tool for those areas of code, such as APIs, that can justify the maintenance overhead of documentation. If developers use javadoc, they should use it correctly, completely and within the bounds of pre-defined standards.
According to Sun Microsystems, 80% of the lifetime cost of a piece of software goes to maintenance. Hardly any software is maintained for its entire lifespan by the original developer. To quote Bruce Eckle1: "Code is read much more than it is written."
This is becoming a key issue for many development organizations, who are focused like never before on costs . . . look at the uproar about off shoring. To get an effective grip on development costs, you need to understand the development process, especially as it relates to the total cost of building and maintaining your software systems.
In a rush to meet an application development deadline, it's easy to neglect style and readability. Things like naming conventions and code consistency, practiced in all computer science programs, are ignored when developers are under pressure to perform. And you, the development manager must oversee the delicate balance between meeting deadlines and producing quality.
For many organizations, quality assessments are a thorny subject. While you try to keep your projects on track, how do you objectively review your team's performance without involving them in costly and inefficient quality reviews?
Coding standards make it easier for developers to read and understand each other's code. Though peer review is relatively new, most developers maintain.or at least step through.someone else's code. A huge amount of development effort is wasted reading undecipherable code. It's amazing how a few style changes can make code difficult to read.
Code commenting is a common area where standards can improve readability. At Enerjy Software, we believe in keeping code comments to a minimum. For those of us who learned software development more than a few years ago, this sounds like heresy.
This new approach to commenting, ."The code is the documentation" .comes from hard-won experience with trying to maintain heavily commented code, where the comments have become out of sync with the code.
Bad or out of date comments are worse than useless: they can cause a great deal of wasted time and frustration. To quote Sun, "When you feel compelled to add a comment, consider rewriting the code to make it clearer."
Javadoc is a great tool for those areas of your code, such as APIs, that can justify the maintenance overhead of documentation. If your developers use javadoc, make sure they use it correctly, completely, and within the bounds of your pre-defined standards.
Everyone knows that the cost of fixing a bug rises exponentially over time. Finding and fixing bugs in the development phase.and preferably prior to unit testing.can save hours of time and resources later on. Adhering to certain coding standards can make it less likely that bugs will be introduced into the code. If those standards are applied as the code is written, the savings will be enormous.
For example, one of the standards from Sun Microsystems' own set2 states:
"Braces are used around all statements, even single statements, when they are part of a control structure, such as an if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces."
This simple coding standard prevents code from failing due to the lack of proper braces around statements. Imagine the time saved on duplicating, reporting, investigating and fixing this one problem.
Using Code Analysis Tools
Code analysis tools such as Enerjy CQ2 Developer Module For Coding Standards give developers an easy way to check their code against a set of standards as it is being written. This is a significant step forward in promoting the adoption of standards, because it makes it easy for developers to police themselves.
The Enerjy CQ2 Developer Module For Coding Standards works like a grammar checker, applying a pre-configured set of rules to the code as developers write it, and listing each violation it finds. In can run manually from within a Java integrated development environment (IDE); and on each File>Save operation. For many of the rules, it even suggests and applies a fix. This is especially useful when dealing with a violation that is repeated throughout the code.
Getting the most from Code Analyzer
To get the most from an automated coding standards tool, you must first define your own rule set. This should be based on rules commonly used by the development team as well as corporate standards. Development teams will gain a lot of value from applying Enerjy CQ2's standard rule set to their code, but they will gain even more if they define their own coding standards first.
It isn't necessary to spend hours crosschecking Enerjy CQ2 rules against your coding standards. Simply run Enerjy CQ2 Developer Module for Coding Standards against your existing code base. For each problem that it finds, either fix your code, or if the error found was actually an element of your coding standard, disable the rule. Later, you can browse through our list of rules to see if any that you have disabled should be turned on, or modified to fit your standard.
We provide hundreds of configurable rules, but you can also define your own. This is as easy as writing new java classes and integrating them with Enerjy CQ2. Within Eclipse, you simply package your new rules into a plug-in using the IDE's extension architecture. Refer to the documentation (PDF and Help) to get started.
Once you've decided on a common rule set and have added any new rules to our existing set, you can share it with all your developers through a common configuration file.
What are the standard rules?
1. Standards Compliance
Enerjy CQ2 checks for things like:
Enerjy CQ2 checks for things like:
Enerjy CQ2 checks for things like:
You can disable each of our rules when you configure Enerjy CQ2 Developer Module For Coding Standards, but you can also disable a rule for a particular file, or an individual statement or group of statements. To disable a rule for an entire file, simply insert a comment before the type declaration that includes a special sequence of characters (ESCA*) and the name of the rule to disable.
You can disable multiple rules with a single comment by separating the rule names with commas. You can disable one or more rules for an individual statement by preceding the statement with a different escape sequence (ESCA-) and the name of the rules to disable.
The most effective way to implement a set of standards is to quickly get to the point where your code generates zero errors, and then keep it that way. Disabling rules is a cleaner approach than trying to remember that certain files generate some errors that can be ignored.
Working With Your IDE
Enerjy CQ2 Developer Module For Coding Standards works with Eclipse, the most popular Java IDE on the market today. Enerjy CQ2 also works with:
By default, the tool is triggered on each File>Save operation, making it virtually seamless as far as the developer is concerned. You can trigger an analysis explicitly if you want; but under normal circumstances, it works in the background, requiring no action.
After each analysis, Enerjy CQ2 Developer Module For Coding Standards reports any violations as a warning message in the IDE. You can navigate to the offending line of code by clicking on the message. Certain rules can be auto-fixed (for example, missing braces) either all at once or one at a time by right clicking on a message.
The help system built into the product is extensive and enlightening. It can be used as a learning tool for new Java developers, or as a handy reminder for more experienced developers. A tap of the F1 key, with the cursor positioned over a warning message, brings up a full explanation of the rule, including references and examples of usage.
Keeping It Simple
Coding standards are increasingly being adopted by development organizations. With 80 percent of the total cost of a piece of software going to maintenance, more effort needs to be directed at ensuring the quality of software at its early stages of development.
Development teams are spending too much valuable time in code reviews, correcting coding standards violations that could be detected.and in some cases corrected.automatically.
Enerjy CQ2 Developer Module For Coding Standards allows a development team to programmatically define and share a common set of standards and then apply them while they are writing code. Once a common set of standards has been defined, it can be shared among a development group.
For any organization that wants to adopt a set of coding standards, or for one that already has a set but needs to do a better job enforcing it, Enerjy CQ2 Developer Module For Coding Standards can mean the difference between a set of standards that is never used and one that is built into every line of code.
Who Is Enerjy Software
Enerjy develops Java™ software integrity solutions for development managers to continuously improve the quality of their application development projects. Enerjy CQ2 is a turnkey solution that includes a full suite of services from installation to training to ensure the system is fully operational and customized for each development manager's unique needs
Development managers can now monitor and modify the behaviors of individual developers, thereby boosting the performance and productivity of the entire team, improving the quality of the code, and correcting the course of the overall application development project. Enerjy Software is a division of Teamstudio, Inc. With headquarters in Beverly, Massachusetts, Teamstudio also has offices in the UK, France, and Japan. To learn more about software integrity solutions designed to improve application quality and enhance developer productivity, please visit Enerjy's Web site at: http://www.enerjy.com.
© Copyright 2006 Enerjy Software. All rights reserved. Enerjy, Enerjy Software, and Enerjy CQ2 are trademarks of Enerjy Software, a division of Teamstudio, Inc. All other trademarks and registered trademarks are the property of their respective owners. Our policy is one of continuous improvement, and we reserve the right to change product specifications without notice.
1 "Thinking in Java," Bruce Eckel, Prentice Hall, 2003
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads