I'm not ashamed to admit that my gut reaction to seeing a block of complex code is fear and trembling. In fact, I'll go so far as to say that you should tremble a little upon encountering extensive methods and sprawling classes. Casting about for an exit sign in these moments is not only perfectly human, it shows good developer instinct. Overly complex code is hard to test and maintain, which means it usually has a higher incidence of defects.

I've explained in previous articles in this series that cyclomatic complexity tends to be one of the harbingers of sticky code. Testing methods with high cyclomatic complexity values is almost always like stepping into a maze -- no easy exit in sight. Last month, I showed you how to use the Extract Method pattern to refactor your way out of the maze. Pushing the method's complexity into smaller chunks makes the code easier to test and maintain, as shown in Figure 1:

Cyclomatic complexity isn't the only complexity measurement for spotting high risk code, however. You can also look out for class length, method length, and intra-class coupling. These measurements are intricately related and also easy to spot. This month, I'll explain why they're important and show you how to track them using PMD and JavaNCSS.

Too much code!

It's important to know the difference between simple code and easy code. Simple code isn't necessarily simplistic or easy to write, it's just easy to understand. You can write simple code in C++ just as easily as you can write it in Visual Basic. The quickest way to de-simplify your code in any language, however, is to write too much of it at once.

Think about how this rule applies to methods and classes. Most of us have trouble memorizing credit card numbers for the simple reason that we can only manage about seven pieces of data (plus or minus two) at once. Knowing this, it makes sense that excessive conditionals are challenging to follow, and hence, hard to test and maintain. This same principle applies to blocks of logic.

Any given body of code usually includes grouped statements that work toward the same goal, such as creating a collection and adding items to it. Grouping numerous blocks of logic in one long method can very quickly cloud the overall intention of the method, however, because few people can effectively handle such a large dataset. It is precisely this weakness that creates maintenance problems in a code base. Behemoth methods are havens for defects because very few people can effectively parse them. So long methods not only do too much work, but they require too much work to understand!

Just as long methods tend to confound developers, so do lengthy classes. The same argument applies to code in the aggregate -- long-winded classes are probably doing too much work and have too much responsibility.

What's too much?

What constitutes a long method or class is, of course, somewhat subjective. For a helpful rule of thumb, you could say that a method with more than 100 non-commenting lines of code is way too long. The actual number varies according to whom you talk to, however. For me, the cutoff point is more like 50 lines of code, whereas some developers would say that a method is too long if it requires you to scroll down to see its entire body. It's up to you to define your own cutoff point.

Similarly, you have to use your own good judgment to determine the correct size of a class. A rule of thumb advocated by many is that a class with more than 1,000 lines of code is too big. 500 lines of code is an easier number for others to stomach.

Back to top

Intra-class coupling

The pattern of complexity increasing repeats itself when it comes to the relationships one object has with other objects. Not only is it somewhat difficult to understand a class that imports numerous outside dependencies or has a lot of public methods, but the resulting increased burden of responsibility leads to brittleness.

I'll start with dependencies. If an object imports more than 80 outside classes, excluding the normal Java™ system libraries, then that class is said to have a high degree of efferent coupling, which means that changes to the imported classes could affect the class itself. In the worst case, if the imports are concrete classes and their behavior changes, then the class doing the importing could break! (See Resources for more on efferent coupling.)

Watching the number of object imports is good for predicting brittleness, but it can be misleading if entire packages have been imported with the .* notation (for example, com.acme.user.*). For more precision, you can pay attention to the number of unique types an object possesses (which is done by parsing the code -- not import statements). The unique types metric can also be helpful if an application's package structure is coarsely laid out in such a way that includes many classes in few packages.

Classes that contain many public methods tend to also have a lot of imports. Such classes usually become central to a code base either as Facades or utility classes. Because of this responsibility (exposed through a large number of public methods), they're said to have high afferent coupling, which also results in a reversed brittleness. If any of these classes change, various, seemingly non-related parts of the application could break.

Back to top

How complexity correlates

By now, a pattern has emerged suggesting that gluttonous code (long methods, too many public methods, excessive conditionals and imports, etc.) impairs readability, testability, and maintainability. Because this pattern repeats itself in various metrics, they all tend to correlate. For example, long methods generally suffer from high cyclomatic complexity values, as shown in Figure 2:

The correlation doesn't stop there, however. Classes with a plethora of imports have many unique types. These classes are typically pretty big. Big classes usually have long methods, and long methods often have high cyclomatic complexity values. Figure 3 shows how complexity metrics correlate:

Back to top

PMD and JavaNCSS

Spotting garrulous code is easy in PMD and (to a lesser extent) JavaNCSS, and both tools are easily incorporated into build platforms such as Ant and Maven.

You can think of PMD as a rules-based engine that analyzes source code and reports any instance of a rule being violated. PMD currently defines close to 200 rules with specific ones for method length, class length, unique types, and counting public methods. You can also define custom rules and modify existing rules (for example, to reflect domain needs).

Customizing PMD

For an example, I'll use PMD's aptly named ExcessiveMethodLength rule for finding long methods. This rule's default length threshold is 100 (meaning that if a scanned method has a length greater than 100 lines, PMD reports a rule violation), but you can lower that threshold if you like.

PMD rules can define properties, which, through excellent foresight on the part of the PMD development team, you can override at run time by using ruleset files. To lower the default value of 100 for the ExcessiveMethodLength rule to 50, you would simply add a properties element to the rule definition and reference the property's name. In Listing 1, I've added a property named minimum to the PMD rule definition:

<rule ref="rulesets/codesize.xml/ExcessiveMethodLength">
 <properties>
  <property name="minimum" value="50"/>
 </properties>
</rule> 

Invoking PMD with a custom ruleset file in Ant requires providing a path to the custom file through the rulesetfiles attribute of the PMD task as shown in in Listing 2:

<pmd rulesetfiles="./tools/pmd/rules-pmd.xml">
 <formatter type="xml" toFile="${defaulttargetdir}/pmd_report.xml"/>
 <formatter type="html" toFile="${defaulttargetdir}/pmd_report.html"/>
 <fileset dir="./src/java">
  <include name="**/*.java"/>
 </fileset>
</pmd> 

PMD reports violations by source file, as you can see in Figure 4. In this case, a few methods were found to have greater than 50 source lines of code:

For long classes, PMD has the ExcessiveClassLength rule, which defaults to 1,000 lines of code. As with the ExcessiveMethodLength rule, it's easy to override the default value with a more apt value. Additionally, PMD has a rule for counting unique types, dubbed the CouplingBetweenObjects rule. For counting imports, check out the ExcessiveImports rule. Both rules are configurable.

Measuring verbosity with JavaNCSS

As opposed to PMD, which defines specific rules for analyzing source code, JavaNCSS analyzes a code base and reports everything relating to the code length, including class sizes, method sizes, and the number of methods found in a class. With JavaNCSS, thresholds don't matter -- it counts every file it finds and reports the values regardless of size. While this kind of data may seem pedestrian (and perhaps verbose!) compared to PMD, it couldn't be farther from the truth.

By reporting all file sizes, JavaNCSS makes it possible to understand relative values, which is often difficult with PMD. For example, PMD only reports files that contain violations, which means only understanding the data for a portion of the code base, while JavaNCSS provides code-length data in context, as shown in Figure 5:

Back to top

In conclusion

Greenfield development, where a development team starts out with a blank IDE console and fills it with beautiful, concise code is a very small slice in the life of a software application. Scores of organizations across the world today are still running applications based on COBOL, which, from a developer's perspective, means wrangling with code written long ago by someone you don't know.

While it's normal to turn nauseous when faced with such a beast, you can only call in sick so many days in a row. At some point, you're going to have to face that massive code block and call it your own. Using complexity metrics for class length, method length, and intra-class coupling (that is, object imports and unique types) is the first step toward understanding what you're up against. Start with some rules of thumb regarding class and method size and then use tools like PMD and JavaNCSS to hone in on the details.

You'll learn a tremendous amount the first time you use complexity metrics on your legacy code base, but don't stop there. By continuously monitoring complexity metrics, you can make smarter decisions and lower your risk while extending and maintaining your code base over time.

Resources

Learn

• In pursuit of code quality: Read the complete series by Andrew Glover.
  
  
• "In pursuit of code quality: Refactoring with code metrics" (Andrew Glover, developerWorks, May 2006): Use the Extract Method pattern to refactor and simplify complex code.
  
  
• "In pursuit of code quality: Code quality for software architects" (Andrew Glover, developerWorks, April 2006): How afferent coupling and efferent coupling metrics reveal the stability of your software architecture.
  
  
• "In pursuit of code quality: Monitoring cyclomatic complexity" (Andrew Glover, developerWorks, March 2006): Learn the simple code metrics that let you spot and correct risky code.
  
  
• "Testing legacy code" (Elliotte Rusty Harold, developerWorks, April 2006): A step-by-step processing for grappling with the ancient beast.
  
  
• "Zap bugs with PMD" (Elliotte Rusty Harold, developerWorks, January 2005): More about PMD's built-in rules and custom rulesets.
  
  
• The Java technology zone: Hundreds of articles about every aspect of Java programming.
  
  

Get products and technologies

• PMD: Scans Java code for problems.
  
  
• JavaNCSS: A simple utility that measures source code metrics.
  
  

Discuss

• Participate in the discussion forum.
  
  

About the author

Andrew Glover is the President of Stelligent Incorporated, which helps companies address software quality with effective developer testing strategies and continuous integration techniques that enable teams to monitor code quality early and often. He is the co-author of Java Testing Patterns (Wiley, September 2004).

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Too much code!
• Intra-class coupling
• How complexity correlates
• PMD and JavaNCSS
• In conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Java on developerWorks

Try IBM Cognos 8 Business Intelligence

Use reports, analysis, dashboards and scorecards to monitor business performance, analyze trends and measure results.

Special offers