Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Code Contracts are Making Slow Progress

Code Contracts are Making Slow Progress

This item in japanese


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.





Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Progress

    by Bruce Robertson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not making slow progress? So they ARE making fast progress?

  • Version?

    by Cheng Michael,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What version you talked about?

  • Re: Progress

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sorry about that. Originally it said "Code Contracts are not making any progress", but I let the article sit for a few days to get feedback on some of the more egregious bug reports. Most of the bugs, especially the thing about readonly fields and VB strings, have been lingering for well over half a year. I had to tone it down a bit once they finally said they are going to fix the string bug, as it shows they are at least moving forward.

    I have to say I hated writing this piece. I wanted it to be a showcase for how well they were doing, but even my utility library the number of false positives was staggering. I spent the better part of two weeks refining my code so it would play nicely with the new FxCop and Code Contract builds, but I just couldn’t make meaningful headway.

  • Re: Version?

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I installed the VSTS version from the link in the article in late November. Based on what I've been reading in the forums I believe that the next build is going to have significant improvements when it comes to functionality.

    As for the syntax, I don't see them changing to a declarative, attribute-based style any time soon. This is sad because there are wish lists dating back to .NET 1.0 with requests for <NotNull> and <Range(min, max)> attributes. Perhaps when "compiler as a service" comes online somewhere around .NET 5 or 6 we can just build it ourselves and emit the correct Contract.Requires code.

  • Re: Version?

    by Ryan Riley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Declarative attributes already exist in the form of DataAnnotations, which are also getting a face lift in .NET 4.0. You could also get a similar effect with the Validation block from the Enterprise Library. I wonder if you understand the intent of Code Contracts. You noted the "if check else throw" style, and those are much closer to what these do for you. I quite like what the Code Contracts team has done, in particular in the use of interfaces for defining contracts to keep the actual class clean.

  • good-for-nothing critics

    by Kostya K,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Code Contracts is an amazing new tool, whatever problems it still has, it's a big step forward developers should be grateful for. The Code Contracts' team did a good job.

  • ValidationAspects

    by Gennadii Donchyts,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ValidationAspects seems to do the many things similar to Code Contracts but the code looks much cleaner:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p