posted on Sunday, January 16, 2005 8:11 PM
by
johnwood
Source Code Metrics Pt 3: Re-Use
Bottom line: you can download a beta utility here that gives you a rough idea of code re-use in any .net dll or exe, combined with complexity metrics.
So far I've covered two ways to analyze your application's size and quality, a C# source code line counter, and a .net complexity analyzer (using the cyclomatic complexity index).
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.
If you want to test this version you can download it here. This version includes (and also enhances) the original complexity analyzer. Enhancements include:
- Re-use statistics
- Method-by-method complexity statistics
- Optional XML output
- Supply multiple assemblies via a .LST file
- Ability to suppress the banner, so output can be redirected to a file.
- Bug fixes
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 shouldn’t 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.
Running the utility is simple, just provide the name of the DLL or EXE as an argument. Any .net binary can be provided, even ones that you didn't write!
For example:
ccmetrics myassembly.dll
Each metric is provided with a hint to help you understand the meaning of the index value.
This gives us three metrics (size, complexity and re-use), but the project isn't complete quite yet. I'm currently looking at coupling metrics (to show me re-usability), and I'll probably also cover other important aspects of running a build including profiling and code coverage tests. To conclude this series I'll create an article bringing all this together. In the meantime let me know if you find any problems with this version!