Code Contracts are Making Slow Progress

Code Contracts are making slow progress towards being ready for production use. While the technology still shows a lot of initial promise, it doesn’t take long to run into a road block or six that makes them unusable in their current form.

One of the most basic and important features of Code Contracts is null reference detection. The ability to detect possible null reference exceptions at compile time would be a huge win for developers. Unfortunately Code Contracts just doesn’t work when it comes to this.

The biggest offender is the inability to understand the readonly modifier on fields. Developers have been using this in C# and VB since .NET 1.0 to indicate that a field can never be changed outside its constructor. Often it is paired with an in-line initializer, making it verifiably clear the field can never be null. Unfortunately the static checker in Code Contracts doesn’t honor the readonly modifier nor does examine the assignments for the field, causing a lot of false warnings.

A big issue for Visual Basic developers is that the static checker doesn’t understand the “If (aString = "")” syntax. Being semantically identical to relatively new “String.IsNullOrEmpty” function, idiomatic VB code uses this for most null string checks. Since the static checker effectively ignores any line that looks like that, VB developers are plagued with lots of additional false warnings. According to Francesco Logozzo of Microsoft, this is finally being addressed in the next release.

Another problem for which no visible progress is being made is the lack of attributes for common scenarios. For example, most functions that return objects will want to ensure the result is not null. This requires this rather tedious code.

Contract.Ensures(Contract.Result(OfSomeType)() IsNot Nothing)
Contract.Ensures(Contract.Result<SomeType>() !=null);

What developers have been asking for is a simple attribute.

<NotNull()>PublicFunctionFoo() As SomeType
[NotNull] SomeType Foo()

Since Code Contracts includes an assembly rewriter, adding attributes that translate into other common scenarios like whether or not a given parameter accepts nulls should be easy. It could even automatically generate the correct code to throw an ArgumentNull or ArgumentOutOfRange exception.

Unfortunately the Code Contracts team has, from the beginning, been antagonistic towards code bases that need to support clients that don’t use Code Contracts. For example, they want to use assertions instead of exceptions for errors that would normally throw ArguementException. This, of course, is totally unacceptable as a failed assertion would automatically crash the entire program without chance for recovery.

Since then the situation has gotten worse rather than better. Turning on runtime checking will actually disable the argument checks written in the “If check Then Throw” style.

A down-right daunting problem facing the Code Contracts team is the sheer size of the .NET framework. In addition to solving some serious issues with both the static checker and the way they deal with non-Code Contract code bases, they have to go back and define the contracts for countless classes. So far even the basic contracts like “For all ICollection<T>, calling Add will increment Count by 1.” are not currently working correctly.

It should be noted that none of these problems can’t be overcome given sufficient time and resources. Code Contracts still remain a very promising technology that over time can greatly reduce or even eliminate whole classes of errors for those with the time and patience to learn these powerful but complicated tools.