Code Contracts, will you use them?

Question

Microsoft just released Code Contracts, a tool that integrates with Visual Studio and allows you to define contracts for your .Net code and get runtime and compile time checking.

Watch the video on Channel 9 that shows how it being used.

For now it's an add-on but it will be part of the Base Class Library in .Net 4.0

Is this something you see yourself using?

I wonder if this means the death of Spec#?

Update

What I mean by the death of Spec# is that we now have 2 different projects for writing contracts:
Spec# is an evolution of C# and it introduces new keywords and behaviours; on the other hand, what Microsoft just released is a library that can be used with any .Net language.
Since the latter looks like it's going to become the de-facto standard, I wonder where that leaves Spec#

Brimstone

+1 for letting me know about this. I had not been aware of it until I saw your question. Hopefully, I can digest this and give you a real answer later... thanks again. – Venola

Make this a wiki? Not really an objective question, just a conversation starter, yes? – Oneill

No wiki, they deprive people who may have something good to say from earning the points they deserve for their answers. – Brimstone

Answer 1

I think the majority of developers using c# 4.0 will use them myself included especially when creating a library that you plan to expose to anyone. It may make your code more verbose in areas but the advantages it has should outweigh the lines of code and time spent.

Vigilante

Answer 2

What do you mean, the death of Spec#? It's the next evolution of Spec#.

And, yes, I plan to use them.

Storebought

Answer 3

To be honest, I had no idea what they were until I saw your question. I don't see the applicability to my organization, so we probably will not use them.

Length

Really? Care to elaborate as to why? Do you have something else in place already? – Brimstone

Did you actually test them out and saw no use , or just "evaluated" for 10 min? – Bentley

@Renaud - the reason is that we have a hard enough time getting developers to write unit tests (let alone do test driven development). Adding another set of classes, or contracts, to each class we develop will just create something else for them to grumble about and skip. Contracts conceptually make sense, but we didn't see the added value if we're already writing unit tests. @ Miau - We tested them out for a little while, wrote a few contracts, and discussed them with the team. None of us really saw any benefit at the time. – Length