Optimizing Quality at the Commit Stage

Static code analysis is a technique for analyzing software application code without actually executing the code. It can be used to measure structural quality on how it meets non-functional requirements of the functional requirements, such as robustness or maintainability.

Higher code quality and stable builds can be achieved when code analysis and code coverage are applied. Applying this level of automation at the commit level improves quality, especially after every commit. Improved test scaling is realized mainly as software complexity increases; automated test execution and coverage keep pace and help maintain the quality of the application.

There are many tools available for Java

• ObjectWeb ASM

• Checkstyle

• FindBugs

• IntelliJ IDEA

• JArchitect

• Jtest

• LDRA Testbed

• PMD

• SemmleCode

• SonarJ

• Soot

• Squale

• SonarQube

• ThreadSafe

Static code analysis does an excellent job of uncovering a specific class of bugs in the application code. However, they often have more to do with the structure of the code, API usage, or usage patterns. They do not evaluate the logic of conformity with the design specifications nor ensure it functions properly. When these tools are incorporated directly into the build process, the overall quality of the builds, as well as the consistency of the application code, is improved in a fast and efficient manner.

Furthermore, this perspective will allow us to understand quality and perhaps build a test scorecard. A scorecard is composed of multiple metrics.

Examples are:

• Bugs per line of code

• Code coverage

• Cohesion

• Connascent software components

• Coupling

• Cyclomatic complexity (McCabe’s complexity)

• DSQI (design structure quality index)

• Function Points and Automated Function Points, an Object Management Group standard[2]

• Halstead Complexity

• Instruction path length

• Maintainability index

• Number of classes and interfaces

• Number of lines of code

In the past, I’ve used two tools for the analysis of Java code which are callable through Maven plugins.

CheckStyle is used to compute traditional static analysis metrics, which are published with each release. The metrics reported are:

• Boolean Expression Complexity

• Class Data Abstraction Coupling

• Class Fan Out Complexity

• N-Path Complexity

JDepend is used for package-level analysis. JDepend traverses Java class file directories and generates design quality metrics for each Java package, including:

• Number of Classes and Interfaces

• Afferent Couplings

• Efferent Couplings

• Abstractness

• Instability

• Package Dependency Cycle

Typically, all static analysis metrics are published to the validation portal through the magic of the Maven Site plug-in. Thus there are Checkstyle reports that contain these metrics for each product release.

These metrics are usually best leveraged by observation over time, although some things can be immediately apparent. These metrics can be used as a means of driving an architecting and refactoring effort in the next release. One must understand what each metric says about the code. That information can then be used to make rational cost-benefit decisions on whether or not action is required.