I recently stumbled upon Microsoft's framework for code contracts.
I read a bit of documentation and found myself constantly asking: "Why would I ever want to do this, as it does not and often cannot perform a static analysis."
Now, I have a kind of defensive programming style already, with guarding exceptions like this:
if(var == null) { throw new NullArgumentException(); }
I'm also using NullObject Pattern alot and have rarely any problems. Add Unit Tests to it and you're all set up.
I have never used asserts and never missed them. Quite the contrary. I really hate code that has lots of meaningless asserts in it, which is just noise to me and distracts me from what I really want to see. Code contracts, at least the Microsoft way are much the same – and even worse. They add lots of noise and complexity to the code. In 99% an exception will be thrown anyway – so I don't care whether it's from the assert/contract or the actual problem. Just very, very few cases remain in which the program states really becomes corrupted.
So frankly, what is the benefit of using code contracts? Is there any at all? If you already use unit tests and code defensively I feel that introducing contracts is just not worth the cost and puts noise in your code that a maintainer will curse when he's updating that method, much like I do when I cannot see what the code is doing due to useless asserts. I have yet to see a good reason to pay that price.
Best Answer
You might just as well have asked when static typing is better than dynamic typing. A debate that has been raging for years with no end in sight. So have a look at questions like Dynamically vs Statically typed languages studies
But the basic argument would be the potential to discover and fix issues at compile time that might otherwise have slipped into production.
Contracts vs. Guards
Even with guards and exceptions you are still faced with the issue that the system will fail to perform it's intended task in some instance. Possibly an instance that will be quite critical and costly to fail at.
Contracts vs. Unit tests
The usual argument on this one is that tests prove the presence of bugs, while types (contracts) prove the absence. F.ex. using a type you know that no path in the program could possibly supply invalid input, while a test could only tell you that the covered path did supply the correct input.
Contracts vs. Null Object pattern
Now this is at least in the same ball park. Languages like Scala and Haskell has had great success with this approach to eliminating null references entirely from programs. (Even if Scala formally allows nulls the convention is to never use them)
If you already employ this pattern to eliminate NREs you've basically removed the largest source of runtime failures there is in basically the manner contracts allow you to do it.
The difference might be that contracts has an option to automatically require all your code to avoid null, and thus force you to use this pattern in more places to pass compilation.
On top of that contracts also give you the flexibility to target things beyond null. So if you no longer see any NRE in your bugs you might want to use contracts to strangle the next most common issue you might have. Off by one? Index out of range?
But...
All that being said. I do agree that the syntactic noise (and even structural noise) contracts add to the code is quite substantial and the impact the analysis has on your buildtime should not be underestimated. So if you decide to add contracts to your system it would probably be wise to do so very carefully with a narrow focus on which class of bugs one tries to address.