You’ll probably be familiar with the idea of checking parameters at member level when writing your classes in order to improve the quality and reliability of your code. The following might be what you’re used to writing/seeing. In fact most of the Microsoft .NET Framework has this littered everywhere. Using red-gate .NET Reflector to view the .NET source will show you type checking. Of course .NET Reflector generates code based on the IL (Intermediate Language) which is not a true reflection of the actual source code, but the intention or what the CLR will actually execute at runtime:

public void Foo(string foo, string bar)
{
     if (foo == null)
        throw new ArgumentNullException("foo")

     if (bar == null)
        throw new ArgumentNullException("bar");
}

You might be thinking, well what’s wrong with that? nothing really from the outset, it gets the job done. But what if now your requirements get slightly more complex in that you need to check for white space too. So now your code might look like the following:

public void Foo(string foo, string bar)
{
     if (foo == null && foo == string.Empty)
        throw new ArgumentNullException("foo")

     if (bar == null && bar == string.Empty)
        throw new ArgumentNullException("bar");
}

You can see how the code is starting to look more complex than it should. You could actually use string.IsNullOrEmpty to achieve the above but for the purposes of this example I used two conditions. This is what we call “plumbing” and the more “plumbing” we have in our code, the harder it is to change and maintain. Also, the above makes code coverage more difficult and increases the cyclomatic complexity to 3 when it could be 1. Cyclomatic complexity is calculated from the number of potential paths through a peice of code. The more potential pass-throughs, the more complex the code. As you can imagine the more parameters we have the the more complex “guard” clauses we need to validate that data.

The first step to tackle this problem is to do what OO is partly designed to solve, abstract those clauses out of the important code and into another object or objects. The simple form of the above could be written as follows:

public void Foo(string foo, string bar)
{
     Guard.ArgumentNullOrEmpty(foo, "foo");
     Guard.ArgumentNullOrEmpty(bar, "bar");
}

That is all there is to it!

So now the number of pass throughs is reduced from 3 to 1. This not only makes testing easier, it simplifies the the code and honours the SOLID principle to OOAD.

The static class Guard in this case can have many members on it that validate all different types of parameters.

Using the Guard pattern is a really simple way to validate and honour code contracts in your code. But recently there has been a programme out of Microsoft Research called….”Code Contracts” – nice name!

It is a more sophisticated Guard. With Microsoft Code Contracts, there is actually static and run-time checking. Static checking meaning when you compile, Code Contracts will check if the contract (pre or post conditions) has been satisfied or not. This is a very powerful feature promoting more reliable and higher quality code. Runtime checking uses a binary rewriter that essentially acts like the Guard clause defined above but offers a templated approach to it.

Microsoft Code Contracts is an implementation of the modern day Guard pattern.

Check it out here: http://msdn.microsoft.com/en-us/devlabs/dd491992

You can download many code samples from the above site.