Enerjy News

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.

Easier Maintenance
According to Sun Microsystems, 80 percent 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 Eckel1, "Code is read much more than it is written."

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.

Bug Pre-emption

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 set² 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
Many well-meaning people have adopted coding standards, only to stop using them. If they are such a great idea, why does this happen?
To implement coding standards, developers must be self-disciplined, remembering each rule as they write code. Consider that Sun's Java coding standards runs to twenty pages. Who could memorize such a list? And what about the developers who have never used coding standards, or those who use a different coding standard? It is not surprising that coding standards quickly fall into disuse.

Code analysis tools such as Enerjy CQ² 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 CQ² 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?
Enerjy CQ² comes with a variety of rules dealing with standards compliance, unused elements, common coding errors and J2EE compliance.

1.  Standards Compliance
Enerjy CQ² checks for things like:

• Correct names - package names should contain lowercase letters only, to avoid issues with case-sensitive systems such as UNIX
• Correct use of javadoc - javadoc should always include an @param tag for each method parameter, to explain the parameter's purpose and any restrictions on input values
• Length of classes - a class or interface that defines too many methods can be difficult to understand. You can configure Enerjy Code Analyzer with a maximum number of methods allowed per class

2.  Unused Elements
Enerjy CQ² checks for things like:

• Private fields and methods - Unused private field and methods should be removed because they cause confusion.
• Local Variables - Often when a developer removes code containing local variables, he or she forgets to remove the initial variable declaration. It should be removed to avoid confusion.
• Method parameters - Unused method parameters should be removed because they cause confusion.

3.  Common Coding Errors
Enerjy CQ² checks for things like:

• Incorrect comparisons - Computers cannot store or perform floating-point computations with floating-point numbers with complete accuracy because of internal rounding errors. If a and b are arbitrary floating-point numbers, it is usually the case that a/b*b != a. This means that it is risky to compare floating-point values for exact equality (using the '==' operator). It is a better practice to ensure that the numbers are sufficiently close.
• Unterminated cases in switch statements - It is a common mistake in java to accidentally allow one case in a switch statement to fall through to the next. Enerjy Code Analyzer ensures that every case ends with one break, return, throw or continue. It is not necessary to apply this rule to the final case in a switch statement, though many developers like to in case additional cases are added to the statement. You can configure Enerjy Code Analyzer to check the last case, or not.
• Missing braces in loop and if-else statements - If the then or else clause in an if expression consists of a single statement, Java does not require you to enclose the statement in braces. This is a dangerous practice, because if the clause is later expanded into multiple statements, it is easy for a maintenance programmer to forget to add the braces, which will cause a bug.
• Local variable hiding fields - It is potentially confusing for a local variable to have the same name as a visible field. For example, it is easy to introduce a bug by forgetting to use "this." to clarify the reference to a field.

4.  J2EE Compliance
Enerjy CQ² checks for things like:

• ejbCreate and ejbPostCreate method signatures do not match - Though the J2EE specification mandates that these two methods must have the same number and types of arguments, it is easy for a developer to let them get out of sync, especially if they are not beside each other in the source code. This problem may not appear until after you have deployed the entity bean into your application server and started it up.

Disabling rules

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 CQ² Developer Module For Coding Standards works with Eclipse, the most popular Java IDE on the market today. Enerjy CQ² also works with:

• IBM WebSphere Studio Application Developer, Version 5.x
• IBM Rational Application Developer RAD) for WebSphere Software, Version 6.0

Integration between Enerjy CQ² Developer Module For Coding Standards and Eclipse is tight. Aside from setting up the rule set, there is no need to perform additional configuration, once it is installed. Enerjy CQ2 Developer Module For Coding Standards reads the configuration data it needs from the project definition in the IDE.

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

2  http://java.sun.com/docs/codeconv/index.html