Jan Schreuder on .Net

Waterfall 2006

I bumped into this link in one of the MSDN blogs. I had to post it. If you're into Agile, or TDD, you gotta check-it-out!!!

http://www.waterfall2006.com/

Professional photography with Windows XP

This post has nothing to do with software development, but everything with Microsoft and digital photography. So I'm posting it anyway.

I'm very happy with the digital camera I bought some months ago, just checkout the image below. At home, I use one PC for storing my photographs, and another for editing, ordering etc. Since August 2005 I have been using Microsoft's SyncToy in order to synchronize both systems. Today, as I was looking for the download location for Synctoy, I found a whole section at Microsoft.com dedicated to digital photography called Professional photograpy with Windows XP. That section on Microsoft.com has a number of interesting articles on digital photography, and you can download a number of tools to make life as a photographer a lot easier.

Why code inspections are useful

I had just read Dennis's post about the switch statement. The code ofcourse is amusing, but I think Dennis proves that code inspections are useful. I still do regular reviews of code, and here's a piece of code I bumped into this morning:

DataSet ds = SqlHelper.ExecuteDataset(

    ConnectionString

    , CommandType.StoredProcedure

    , _SpGetAllData);   

try

{

    ds.Tables[0].TableName = _TableName;

}

catch (SqlException sqlEx)

{

    throw new mySqlException(sqlEx);

} 

The mySqlException that is thrown adds additional information to the SqlException which is used by the application to provide sensible error messages to the user. But as you judge by yourself, that this will never happen for the ExecuteDataset call. It does prove (I think) that code inspections or reviews can help improve software quality.

Note: The code has been editted to protect the privacy of the original author. And no, it wasn't me!

Dispose and the Garbage collector

I was assigned to a .Net web project some years ago to see why the application continued to allocate more and more memory untill IIS thought it was to time to restart the application. I solved a lot of the problems in that project simply by calling the Dispose method on any object that implemented one, once I didn't need that object anymore. Since then, I've tried to make it a rule to call the dispose method for all objects that expose that method.

But I still see projects where this doesn't happen. When I discus this with the developers on that project, they are under the impression that it is not necessary to do this. People think that the Garbage collector will clean up resources. Well, it might but you never know when! I believe it is good practice to call the Dispose method on any object that exposes it once you no longer need that object. The Dispose method will clean up any resources that need to be cleaned up. For example, the SqlConnection object will clean up anything related to the connection, especially the unmanaged resources that the GC will never touch!

I found some interesting reading on the subject of Dispose, Finalize and the garbage collector!

• Joe Duffy: Dispose, Finalization and Resource Management Design Guideline
• Chris Lyon: To Null or Not to null
• Chris Lyon: A list of Garbage Collector links
• Chris Lyon: Dispose do's and don'ts
• Chris Lyon: Demystifying Dispose

Using code analysis tools

If you're not interested in someone expressing his feelings about checking code and code quality, please skip this post. If you're still reading this, then I assume you're interested and I would really like you to comment on this subject.

I've been working on several projects for various clients of the company I work for. And I run into the same things over and over again, namely the feeling that people just don't use the tools that are available to them.

FxCop

Take for example FxCop, a tool we all know, or at least, we should. FxCop is a code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework Design Guidelines. It's freeware and developed by Microsoft, so you may assume that the things the tool checks for are worth checking. Each time I get involved in a project that has already been running for some period of time, I run FxCop on the existing code. And each time I'm surprised at the problems it finds. And not just the type of problems, but also the number of times these problems occur in the code.

Now I will be the first to agree when people say that FxCop can be a pain in the proverbial ass, complaining about typing errors and uninitialised variables. But there are plenty of other problems that FxCop checks for which should be investigated if you want to be sure the code you've developed is up to a certain quality level. I think everyone should try and eliminate as much of the errors as possible. Of course there will be problems that you cannot solve, or that are acceptable in your situation. But then you have the option to disable these rules.

Code complexity checks

Another thing is the size of some of the methods created by developers. I've blogged about code complexity before and so has my good colleague Rene Schrieken. We both use a tool called DevMetrics from Anticipating Minds, but there are others. When you run these tools, they will produce a list which contains a value showing the complexity for each method. If you like to know what these numbers mean, please check my previous blogpost. But in general any method with a complexity higher than 50 is considered untestable by any of the tools I've used so far. And trust me, I still see methods with figures of 100 and up. Usually these methods are 600+ lines long. I normally try to split them up into several smaller methods to make things more understandable.

So what do you think?

Let me know how you feel about these two subjects.