CCMetrics Complexity Analyzer
Download here!
 

Another important metric to follow is the amount of re-use in your application. Re-use is considered to be code that is invoked by two or more other methods, and it's a very important facet of good design in an application. As development progresses on a project, I want to make sure that the amount of code re-use increases as the developers increase their understanding of the application and commonality between components, and so I want a utility that can tell me how much re-use is present in a software project so I track it on a day to day basis.

Note that there's a difference between re-use and re-usability (or the potential for a method to be re-used), and I'll be covering that in a future posting. Right now we're just focusing on how much code re-use is present in a particular application, and not whether that code is capable of being re-used.

One way to calculate a re-use index is to see which methods are called by other methods (a call graph) and somehow process data. This is useful, but it doesn't give me the whole picture. What I'm also interested in is how this helps the overral complexity of the application, not just whether a method has been re-used: I want to determine how much of the complexity of the application is being re-used. In essence, I think it is more acceptable for a highly-reused method to be complex, than an orphaned method that is used only once. Therefore we should be easier on complexity that is re-used in multiple places. Surprisingly I've found little research into measuring the amount of re-use in code, so I'm winging this a bit.

I've modified the complexity analyzer to take re-use into account, providing me with both the average cyclomatic complexity, and a new figure that reduces the cyclomatic complexity based on the method's re-use. The two figures are then aggregated into a figure that tells you what percentage of the complexity of your application is re-used - and the higher this figure is, the better.

In addition to this I'm providing the amount of code re-use. This is determined by increasing the logical size of a method depending on how many times it's called, summing all method sizes together and comparing this to the original application size to create a ratio. The ratio tells us how much general code is re-used in the application.

Also, if you're looking for some insight into the meaning of cyclomatic complexity metrics, you can read this (http://www.aivosto.com/project/help/pm-complexity.html) - to summarize though, the general rule is that the complexity index shouldnt increase beyond 10 per method, or 120 per class (based on the assumption that you shouldn't have more than 12 complex methods in your class) . Anything beyond that and you should look at simplifying the code a bit.

Another feature of ccmetrics is to measure something called "coupling" of code. In a world of extreme programming and service orientation, the trend is to write loosely coupled components that can be easily re-used in future applications with minimal changes. Coupling is really the easiest way for us to determine the re-usability of a class, and the good design of an application.

As part of my build I want to see just how re-usable the code in my project actually is, and I want to see whether a specific change or new feature in the project has somehow affected the overall re-usability of the project.

So what constitutes coupling? Quite a lot of research has been done in this area, especially by Chidamber and Kamerer who devised an index known as "CBO" or "Coupling Between Objects".

The gist of the research is this: Whenever we reference another class in our component's implementation, we're tying ourselves to that class. A reference includes both property accesses and method calls. This means that if we want to use that component later on, we'd have to make sure those dependencies were also available and this complicates our ability to re-use that component.

This can't be said of method calls to interfaces though. Calling a method on an interface instance does not constitute coupling, because the implementation of that interface can easily be replaced, so you're no longer bound to the specific class and can implement the interface yourself making re-use a possibility.

You can read more about Chidamber and Kamerer's work here http://www.pitt.edu/~ckemerer/clnieee.pdf.

Based on my understanding of this metric, I've enhanced my CCMetrics command-line utility so that it now also reports on the coupling of methods and classes. In this case, the coupling index is calculated based on the number of unique classes referenced that are not interfaces. The unique references are counted at the method level as well as the class level. The most-coupled class is reported in the summary, and individual method couplings can be seen in the XML output.

Then I want to run CCMetrics on the list. Running CCMetrics without any arguments provides you with a list of the possible arguments:

3. I'll then concatenate these two files together (a dos command such as "type analysis_old.txt >> report.txt" would do this), and send the resultant report.txt file via email. To send it from the build I'll be using this tool.

For more information please visit the forum to discuss. Source code is not available at present - click here to download.

If you find this utility useful, please make a donation by clicking the button below (suggested donation is 10.0 USD)!

Change Log