How mature is the Microsoft Code Contracts contract structure?

Question

Microsoft recently released its free version of Code Contracts on DevLabs with a commercial license. We are interested in using them in our project (mainly C #, some C ++ / CLI) in order to gradually replace all custom validation code, but I really want to learn about how other people came across it before what we did it with, namely:

• Do you think the structure is mature enough for large and complex commercial projects?

• What problems did you encounter while using?

• What benefits did you get from him?

• Currently hurt than worth it?

I understand that this is a somewhat subjective question, because it requires an opinion, but given that this structure is a very important part of .NET 4.0 and will (potentially) change the way the verification code is written, I hope this question will be left open for collecting experience on this issue, to help me decide on a specific, responsible issue:

Should we start using it next month?

Please note that we are not sending the API code, but only a web service, so for most compatibility with code in terms of exception type this is not a problem. However, since I hope that more people than just me will benefit from this post and its answers, any detail around this area is more than welcome.

Answer 1

I have already played with codes that contract even more on a small but moderately complex standalone project that should inherit some BCL classes and use others.

Contracts look great when you work in a completely isolated environment with only native code and primitive types, but as soon as you start using BCL classes (which before .NET 4.0 do not have their own contracts), the verifier cannot check if they will violate any either from requirements / collateral / invariants, and therefore you will receive many warnings about potentially unsatisfied constraints.

On the other hand, it detects some unacceptable or potentially unsatisfied constraints that could be real errors. But they are very difficult to find, because there is so much noise that it is difficult to know which ones you can fix. You can suppress warnings from BCL classes using the adoption mechanism, but this is somewhat self-proclaiming because these classes will have contracts in the future and assumptions will reduce their value.

So, I feel that at the moment, because in 3.5 we are trying to build a framework that the verifier does not understand enough, it is probably worth waiting for 4.0.

Answer 2

The last mature answer to this was in 2009, but .NET 4 is missing. I suppose we need an update:

Code contracts may well be mature enough for your Debug releases.

I understand that this is more likely an upgrade from "harmless" to "basically harmless."

The Code Contracts home page contains links to fairly comprehensive PDF documents. The documentation provides recommendations for use in section 5. To summarize, you can choose how brave you feel that the contract tools are rewriting your IL in your release versions.

We use the "Do not rewrite my IL release" mode.

So far, I liked this unexpected advantage the most: there is less code, so less code to test . All your protective disclaimers are melting.

if(arg != null) { throw new ArgumentNullException("arg"); } // Blank line here insisted upon by StyleCop 

becomes:

 Contract.Requires(arg != null); 

Your functions are shorter. Your intention is clearer. And you no longer need to write a test called ArgumentShouldNotBeNull to achieve 100% coverage.

So far I have had two problems:

• I had a unit test that relied on contract failure. You can argue that having a test was a mistake, but I wanted to write this specific prohibition in the form of a test. The test failed on my build server because I did not have the tools installed. Solution: install tools.

• We use two tools that rewrite IL: Code Contracts and PostSharp . They did not get along too well. PostSharp 2.0.8.1283 fixed the problem. I would carefully evaluate how all two IL rewriting tools work.

So far, the benefits have outweighed the dangers.

Resolving obsolete issues raised in other answers:

• The documentation for code contracts is fairly comprehensive, although, unfortunately, in PDF format.
• There is at least one forum with a contract code hosted by Microsoft.
• Contract Code The standard version is free if you have a VS2010 license.
• .NET 4 is missing. I came across Microsoft contracts when implementing common collection interfaces.

Answer 3

Judging by this thread, I would say that it is not mature enough to use it for an enterprise-level project. I have not used it myself, but people still encounter errors that will stop your critical project. This seems like a really great frame, and the examples of the videos they provided were exciting, but I would wait:

• The existence of a community forum. . You will want to discuss the inevitable problems that you face with other developers, and you want to know that there is a decent base of developers there to discuss solutions with.
• Successful release of a pilot project. . Usually, when Microsoft Research releases what they think is ripe enough to be used in a commercial project, they will work with the organization to pilot it and then release that the open source project is proof of concept and trial version of all the basic functions. This will provide greater assurance that most common contract scenarios are covered and work.
• More complete documentation. . Simple and simple, at some point you will want to do something with contracts that you cannot use with Microsoft Code contracts yet. You want to be able to quickly and clearly explain that your scenario is not yet supported. The current documentation will make you guess and try different things, though, in my opinion, which will lead to a lot of wasted time.

Answer 4

He is not mature enough.

This will happen as soon as Microsoft releases it with available versions of VS, but without static code analysis it will not be used at all.

The VS editions that have it are so insanely expensive that only a handful of people can ever afford it.

Microsoft's shame killed this amazing idea with its pricing policy. I want code contracts to become mainstream, but they won't.

Epic glitch.