Code Analysis with JavaNCSS
July 2, 2007 · by Scott Fradkin
One of the things that I’ve been getting into lately is the usage of various code analysis tools as part of a standard build. There are numerous tools that can be very helpful when used as part of a continuous integration process.
One of the most common static analysis tools is JavaNCSS. It’s a simple tool and it doesn’t do all that much, but I think that it can be beneficial to use.
You point JavaNCSS to your source files and it will output the number of NCSS (Non-Commenting Source Statements) per package, class, and function. Just for kicks, it also calculates the CCN (Cyclomatic Complexity Number) for each function and displays the number of Javadoc comments per package, class, and function. Some of this may seem a bit useless and even pointless, but I think that there’s value to all the information that it calculates.
Most people would look at the number of lines of code and say “whoop-dee-doo!”. Yeah, it is kind of hokey. “Look! I coded 1000 lines today! Bonus time!” Seriously, though. The number of lines of code probably makes more sense to track at the function and class level. If the number of lines of code for a function is large or has been increasing over time, there might be an opportunity to take another look at that code to determine if extra functionality is creeping into the function that shouldn’t be there. If the number of lines of code in a class seems large, then perhaps the class has functionality inside of it that would be better in a different class.
The CCN can be used similarly. The CCN (aka, the McCabe Metric, http://en.wikipedia.org/wiki/Cyclomatic_complexity) is a number that describes the complexity of the code. There’s a whole complex discussion about it on the Wikipedia entry, but basically it’s a measure of how much branching there is in the code. If the number is low, then the code is very straightforward and does not have many decision points. If the number is high, then there are a lot of decision points (if/then/else statements, loops, switch statements, etc.). Generally, if the number is high for a method it could possibly be a candidate for refactoring. Take a look at the method to see if the decision points can be compressed together, or if some of the branching is unnecessary, or if the method could be logically split up into other reusable methods. Many times, however, despite a large CCN there is a reason the method is written how it’s written and that’s ok.
Lastly, I actually like the Javadoc counter. Looking at the counts per function makes it really easy to spot which functions are lacking documentation.
JavaNCSS is a nice little tool to help out with some basic static code analysis. It can be found here: http://www.kclee.de/clemens/java/javancss/
Filed in: Team Member Blog Comments (0)
Comments
There are no comments for this entry.
Commenting is not available in this section entry.