Update: As Chris Nahr pointed out, there’s a blog post by Melitta Andersen of the BCL team explaining this in more detail.

Obviously I’ve been looking at the proposed C# 4.0 features pretty carefully, and I promise I’ll blog more about them at some later date – but yesterday I watched a PDC video which blew me away.

As ever, a new version of .NET means more than just language changes – Justin van Patten has written an excellent blog post about what to expect in the core of thee framework. There are nice things in there – tuples and BigInteger, for example – but it was code contracts that really caught my eye.

Remember Spec#? Well, as far as I can tell the team behind it realised that people don’t really want to have to learn a new language – but if the goodness of Design By Contract can be put into a library, then everyone can use it. Enter CodeContracts…

Actual examples are relatively few and far between at the moment, but the basic idea is that you write your contracts at the start of methods – not in attributes, presumably because that’s too limiting in terms of what you can express – and then a post-build tool will “understand” those contracts, find potential issues, and do a bit of code-rewriting where appropriate (e.g. to move the post-condition testing to the end points of the method). Object invariants can also be expressed as separate methods.

Rather than guess at the syntax in this blog post I highly recommend you watch the PDC 2008 video on both this and Pex (an intelligent code explorer and test generator). The teams have clearly thought through a lot of significant issues:

• Contracts can be enforced at runtime, or stripped out for release builds. (I’ll be interested to see whether I can keep the pre-condition checks in the release build, just removing invariants and post-conditions etc.)
• If you’re stripping out the contracts, you can still have them in a separate assembly – so if you supply a library to someone, they can still have all the Design by Contract goodness available, and see where they’re potentially violating your preconditions
• Contracts will be automatically documented in the generated XML documentation file (although this has yet to be implemented, I believe)
• Interfaces can be associated with contract classes where the contracts are expressed. (They couldn’t be in the interface, as they require method bodies.)
• Pex will be able to generate tests in MS Test, NUnit and MbUnit. (Hooray! This got a massive cheer at PDC.)

Now I should point out that I haven’t tried any of this – I’ve just watched a video which was very slick and obviously used a well-tested scenario. If this genuinely works, however, I think it could change the way mainstream developers approach coding just as LINQ is changing the way we see data. (Obviously there’s nothing fundamentally new about DbC – but there’s a difference between it existing and it being mainstream.)

I’m really, really excited about this :) Definitely time to boot up the VPC image when I get a moment…