Archive for December, 2007

Checkins

Dec 13

One thing that I have picked up as a good habbit is when to check source code in. I remember a day when I would check out in the morning and check it in when I went home.

The best habbit I have gotten into is doing a checkin when the code is in a working state. This could be when all of my tests pass or when a manual test is successfull (if you don’t have tests or good coverage). I think this probably happens more due to the use of a continuous integration server that you can get feedback on code you just commited very quickly.

I now find myself doing a checkin every 15-20 minutes which has several bennefits:
-Other people on my team never run into something where their change and my change is not compatable. This is due to short changes so we are only 15-20 minutes out of sync and working on seperate pieces.
-If I really screw up something. I can rollback my code to a point in time and loose very little work
-I get quick feedback on my changes from the build server. I know that something I did in the last 15 minutes broke the build and not something I did over the last 1-3 days.
-It keeps me focused on writing the smallest code to get something working and to not leave loose ends laying around

Filed Under: General

Region Replacement RegEx

Dec 11

I recently took over a project that was quite region heavy (ok every property, function, and field was wrapped in a region). So to remove them I wrote a little find replace regular expression that I thought I would share:

^\#Region\ “[a-z0-9A-Z- ]*”$

 

Filed Under: Uncategorized

Interface Chaining in VB.NET

Dec 10

One beef I have had with vb was that I thought you could not chain interfaces like you can in C#:

Public Interface ICommand: IDisposable
{
 void AddParameter(string name, object paramValue)
 IDataReader ExecuteReader()
 int ExecuteNonQuery()
 Object ExecuteScalar()
}
 
Finally a colleague of mine told me that instead of implementing an interface on an interface you inherit the interface like so:
Public Interface ICommand
    Inherits IDisposable
    Sub AddParameter(ByValname As String, ByVal paramValue As Object)
    Function ExecuteReader() As IDataReader
    Function ExecuteNonQuery() As Integer
    Function ExecuteScalar() As Object
End Interface
 
So simple (still feels weird to inherit an interface but in this case it does make sense)
Filed Under: General

NDepend

Dec 6

I have been playing with NDepend for the past few months and am quite impressed. The sheer power of this tool has been quite intimidating and I have been putting off this post as I really wanted to learn NDepend before I wrote my opinions (I still don’t know it very well but that will take more time)

For those who have not hear of it, NDepend is a great analysis tool that quickly and easily allows you to spot issues in your code base. It ships with over 50 built-in metrics some of which are number of lines of code, number of types, percentage of comment, lack of cohesion of methods, cyclomatic complexity, depths of inheritance trees,  and so many more. These metrics are quite good I find and I have never had to tweak any of them or ignore some. I think that is what impressed me most about the tool.

The tool outputs quite large reports via a web page. This is nice and handy but also a little too large it seems. There is probably a way to customize the output to drop out many of the things that I don’t find useful all the time. For instance there is a reference map diagram that gets generated to show the dependencies on other assemblies which is useful once in a while but not always.

There is also the ability to easily specify your own rules using the Code Query Language (CQL). I have never had to do this but the ease that you can add your own metric is a huge plus and does not intimate knowledge to create one (like FxCop does for instance). CQL is a SQL like language so the only thing a developer would need to learn is the keywords for CQL I would think. A sample CQL rule would read like this: select methods where NbLinesOfCode > 30 and IsPublic. Its human readable and easy which is what we all want.

When I first started playing with NDepend I found the UI…clunky. In the past few versions the UI has really become a first class part of the application and feels a lot more fluid. The unfortunate part of the application is that there is a lot of data presented up front which is quite intimidating. I can not really think of any ways to simplify it though so I think it is a necessary compromise.The authors have done a really good job of presenting lots of data and different ways to look at the data quite well.

ndepend 
I have really grown to love this bubble graph shown above. This is a great visualization of the number of lines of code in my application. The vertical yellow lines show assembly divisions and then the harder to see orange boxes are namespaces. The ovals are classes and the bumps within them are methods/properties. This is such a fast way to spot issues as you can see in the Demo.Data.Darts has a lot of large methods in it as it is a big unbroken oval. In 5 seconds I can spot large classes/methods which are almost always the biggest pain points in an application (the graph is interactive too so you can zoom in and hover over methods for more information). Also note that right from the graph toolbar you can change the metric displayed to many other things (like number of parameters, cyclomatic complexity, number of variables, and more). The speed that I can find problem areas is the amazing power of this tool.

I have been running NDepend against two projects, one new and one old. What has surprised me is that I find it more useful on the old project. I can easily spot the problems and go and fix them. For the new project it is nice to confirm that the code base meets my own metrics. Granted it is only me working on the new project so I don’t see it straying from what I want it to do. If I had other developers I think I would use this tool more as a good way to spot poor code being contributed before it becomes problematic (and yes you can plug NDepend into cruise control but I have not tried this as of yet).

I feel this tool is quite valuable to any team concerned with code quality (hopefully that is everyone). The tool seems so comprehensive it is hard to say that you use even 10% of it but if you use even the basics I am sure it can help out (I know it has for me). The only thing I don’t like is that it is not free like the other tools I have in my toolbox (1 license is US$425 right now). Prices also drop the more licenses you buy which is also nice. After working with it I would say that it does add value to what I do and the $400 is a small price to pay for a tool like this. There is also a trial you can download too to try it out which I encourage you to do.

Filed Under: General