This project has moved and is read-only. For the latest updates, please go here.

Differences with .NET 4.0 CodeContracts

Jun 8, 2009 at 11:15 PM

Aside from syntactic differences, is the only difference between your library and the CodeContracts library static checking (breaks compilation if contract is broken)?  Might create a conflict if this feature was developed and had both installed...I dunno.

Jun 9, 2009 at 8:39 PM

There are a few differences between CuttingEdge.Conditions and Code Contracts. The most important differences are:

  • Code Contracts supports compile time / static validation, while CuttingEdge.Conditions only supports runtime checking.
  • Code Contracts supports checking preconditions, postconditions, invariants and interface contracts, while CuttingEdge.Conditions only supports checking preconditions and postconditions.
  • Code Contracts supports a very simple API where a user must supply a predicate, while CuttingEdge.Conditions has a very sophisticated fluent API.

While CuttingEdge.Conditions aims at precondition (argument) checking and throwing exceptions that obey the Framework Design Guidelines, Code Contracts allows us to prevent exceptions been thrown at the first place by providing compile time errors, which is of course much better than what CuttingEdge.Conditions can offer. On the other hand, CuttingEdge.Conditions offers an API that allows developers to quickly and efficiently write very readable preconditions.

Using both CuttingEdge.Conditions and Code Contracts in a single project should not be a problem, but the preconditions written with CuttingEdge.Conditions can not be compile time checked by the Code Contracts verifier. However, this is something I really like to address. I really like CuttingEdge.Conditions to evolve as a 'plugin' on top of Code Contracts in such a way that developers can write preconditions using the fluent API of CuttingEdge.Conditions, while getting the compile time support supplied by Code Contracts and of course still being able to use Code Contracts for all features CuttingEdge.Conditions lacks. However, I know this won't be easy to achieve.

I hope this answers your question.

Jun 9, 2009 at 10:46 PM

Thanks for the detailed info.  I like the rigidness of your fluent API for easy reading/debugging, but I also like the flexibility of the code contracts predicates usage, too, for complex and multi-variable contracts.  I do applaud your efforts, regardless of how things turn out for your project down the road b/c this is something I have been mulling over for the past five years until I heard about code contracts and decided to wait for its release.  I didn't know you had developed CuttingEdge.Conditions, or I might have been able to use it before now...