Monday, January 17, 2005 - Posts

Using CCMetrics in your build

Now I've finished my code analysis tool I'm going to integrate this into my nightly build. If you want to do the same, just follow these instructions!

1. Firstly I generate a list file of all the assemblies I want to include in my analysis. Personally I'm going to generate this manually but you could also generate this from a quick "dir *.dll /b > files.lst" command.

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

CCMetrics v0.2 beta, (c) 2004, 2005 J. Wood Software Services LLC
Experimental Software - Use At Your Own Risk!
 
Usage: CCMetrics filename.dll [/x] [/b] [/f path]
 
CCMetrics takes a .Net DLL (or .EXE) and determines the cyclometric
complexity of the projects contained therein.
 
filename.dll is the name of the assembly or executable to analyze.
A *.lst file can be supplied that contains a list of assemblies to
analyze.
 
/m specify the number of methods to display, the default is 6.
/x generates XML output.
/b suppresses the banner.
/f can be used to override the folder to the .Net Framework SDK.
 

The XML output (/x) generally gives you a lot more detail and might be useful when you want to delve into a particular problem, but for the nightly build just the summary will do for me.

My basic requirement is to create a file containing summary statistics of the files, and then mail this out to me every night. So I think I'll end up using a command like this:

CCMetrics files.lst /b /m 10 > analysis.txt

Note that I've upped the number of method stats from the default (6) to 10. This is just personal preference. I've also included /b to suppress outputting the banner, so I can concentrate on just the data.

2. Before I run this command, I want to back up yesterday's analysis.txt so I can compare the values each day. I'll use a simple rename to call the old file "analysis_old.txt".

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.

And we're done. Hopefully I should get an email each day of both today and yesterday's code statistics so that I can compare the values, monitor trends in changes, and be alerted to project changes that add unusual complexity. All in all, I really hope this will help me keep on top of things.

I think it would be really cool if I could graph this data, keeping a history of the analysis taken each day, and then mail out the graph or put it up on a project web page. In the meantime, though, I think this simple text report will suffice.

I hope you find it useful.

posted Monday, January 17, 2005 1:22 PM by johnwood with 1 Comments

Free SendMail Utility for Windows

Download a beta of FreeSendMail here.

I spent a little while looking around for a command-line mail send utility, something like Unix's SendMail. But all I found were products that would cost me $20 or more! Maybe I didn't look hard enough, but like many I make the assumption that if things aren't on the first 2 pages of Google then they effectively don't exist or at least aren't any good.

The thing is, .Net gives you everything you need to send email, in an SmtpMail class. To send mail from the command line, I just had to expose this class - and how difficult could that be?! It had to be another 10 minuter.

So once again I did it myself. To save others the hassle of searching through google, or paying cash, I've compiled it into a simple command-line utility and put it up on my website.

When you run it you get:

Free SendMail v0.1 Beta, (c) J. Wood Software Services LLC

usage: sendmail /s mailServer /f from /t to /m filename /j "subject" [/h(tml)]

Sure it's nothing fancy, but it appears to get the job done from the limited testing I've run.

Here's an example of how you might use it:

sendmail /s mymailserver.com /f "John Wood <john.wood@mail.com>" /t "Bill Goats <billg@murkysoft.com>" /j "invoice 205123" /m mailbody.txt /h

If /H is specified, then the contents of the file should contain HTML text, otherwise it should contain plan text.

Download it and let me know what bugs you find.

Addendum: Since posting this I was reminded of the open source Blat utility (http://www.blat.net/194/) which offers far more features. But hey, if you like simple with C# source...
posted Monday, January 17, 2005 12:58 PM by johnwood with 34 Comments

Source Code Metrics Pt 4: Coupling

To wrap up my adventure into complexity analysis I'm going to cover 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.

You can test this utility by downloading it here.  Let me know if you find any problems.

 

posted Monday, January 17, 2005 11:38 AM by johnwood with 1 Comments