Overview

Code Contracts bring the advantages of design-by-contract programming to all .NET programming languages. The benefits of writing contracts are:

Improved testability

each contract acts as an oracle, giving a test run a pass/fail indication.

automatic testing tools, such as Pex, can take advantage of contracts to generate more meaningful unit tests by filtering out meaningless test arguments that don’t satisfy the pre-conditions.

Static verification We have prototyped numerous static verification tools over the past years. Our current tool takes advantage of contracts to reduce false positives and produce more meaningful errors.

API documentation Our API documentation often lacks useful information. The same contracts used for runtime testing and static verification can also be used to generate better API documentation, such as which parameters need to be non-null, etc.

Our solution consists of using a set of static library methods for writing preconditions, postconditions, and object invariants as well as three tools:ccrewrite, for generating runtime checking from the contracts

cccheck , a static checker that verifies contracts at compile-time.

, a static checker that verifies contracts at compile-time. ccdoc, a tool that adds contracts to the XML documentation files and to Sandcastle-generated MSDN-style help files.

The use of a library has the advantage that all .NET languages can immediately take advantage of contracts. There is no need to write a special parser or compiler. Furthermore, the respective language compilers naturally check the contracts for well-formedness (type checking and name resolution) and produce a compiled form of the contracts as MSIL. Authoring contracts in Visual Studio allows programmers to take advantage of the standard intellisense provided by the language services. Previous approaches based on .NET attributes fall far short as they neither provide an expressive enough medium, nor can they take advantage of compile-time checks.

Contracts are expressed using static method calls at method entries. Tools take care to interpret these declarative contracts in the right places. These methods are found in the System.Diagnostics.Contracts namespace.

are expressed using static method calls at method entries. Tools take care to interpret these in the right places. These methods are found in the namespace. Contract.Requires takes a boolean condition and expresses a precondition of the method. A precondition must be true on entry to the method. It is the caller’s responsibility to make sure the pre-condition is met.

takes a boolean condition and expresses a precondition of the method. A precondition must be true on entry to the method. It is the caller’s responsibility to make sure the pre-condition is met. Contract.Ensures takes a boolean condition and expresses a postcondition of the method. A postcondition must be true at all normal exit points of the method. It is the implementation’s responsibility that the postcondition is met.

Full details are in the user documentation.