Microsoft Code Contracts and Specifications

13 October 2009 | Eric Swanson | Development, Microsoft | Tags: , , , , , , , ,

All developers write code with input expectations, code assumptions, and output guarantees (we’ll refer to these as code contracts). My presentation Microsoft Code Contracts - Explicit Expectations helps introduce developers to a new framework available to make those code contracts explicit. The appropriately named project, Microsoft Code Contracts, will ship bundled with .NET 4.0 (codenamed Dublin). However, because the project evolved from the Microsoft Research team’s Spec# project, Code Contracts has already been released for .NET 2.0+ applications.

View: Microsoft Code Contracts - Explicit Expectations

*Also view the BCL Team Blog’s entry “Introduction to Code Contracts” from last November after the PDC presentation.

**View the Code Contracts site.

5 Responses to “Microsoft Code Contracts and Specifications”

  • 1 Mike Barnett Says:
    October 16th, 2009 at: 9:50 pm

    Great! Thanks for doing this. The only thing I thought I should point out is that we consider all property getters to be pure by default, so you don’t really need to mark them as such.

    Mike

  • 2 Eric Swanson Says:
    October 19th, 2009 at: 6:13 pm

    Great to know Mike! Thanks for stopping by.

  • 3 David Kreth Allen Says:
    November 3rd, 2009 at: 8:18 pm

    Have you used code contracts for any of your commercial work? I’ve been using it for many years. I first learned of Design by Contract with Eiffel. Then I wrote a javascript framework. Then I adopted a home-grown library written by Robert McFarland for C#. Now I use Microsoft Code Contracts in C#.

    But I find most developers have no idea of it, nor the benefits it can bring. You obviously have an interest. And I wondered whether you have introduced contract code for any of your clients.

    Thanks

  • 4 Eric Swanson Says:
    November 4th, 2009 at: 8:00 am

    David - Yes, I began using the library commercially once it was made ‘official’ through the planned release of .NET 4 as well as through DevLabs. I will usually attempt to be ‘familiar’ with the ideas floating in the community, like Spec# in the Research dept, and only make a more concentrated effort to utilize technology when adoption reaches a threshold of community awareness. I don’t use a hard-and-fast rule for determining this point.

    I agree. Most developers don’t know about it and will not care for it until they can embrace the principles behind it. Most of the time, it’s challenging to simply get developers to reuse code from their peers, embrace TDD and Continuous Integration, or simply to use quality parameter and variable validation and basic logging and tracing…

    Oh, and throw a curve ball in the mix: Dynamic Languages will arrive in .NET 4.0, so you can throw principles right out the window for a lot of developers out there. Fortunately, I think the dynamic language community will continue to push very hard on TDD, continuous integration, and behavior-driven development. But, unless enforced, we can all plan to fix more bugs in sloppy code. For those who took offense to these statements, I will point out: I am an advocate for dynamic languages with the right processes in place to ensure quality deliverables. They can be a great time saver; I just don’t want the time saved to translate into bugs.

  • 5 Matt Call Says:
    November 15th, 2009 at: 12:11 pm

    Thanx for your very useful post. But I had difficult time navigating around your web site because I kept getting 502 bad gateway error. Just thought to let you know.

Leave a Reply