Design by Contract in C#

Is there a basic DbC framework that I could use in VS2008 and Mono ?

No!

Code contracts are not even out, then there would have to be port to mono.

Charles said:

http://research.microsoft.com/projects/contracts/

C

I also have a tutorial I have written here

vesuvius said:

Charles said:

*snip*

I also have a tutorial I have written here

I took a look at the System.Diagnostics.Contracts namespace, and it's seriously a very small interface. I assume most of the work implementing Code Contracts is modifying the compiler?

peli said:

Charles said:

*snip*

Contracts is simply an API. The Code Contracts project from MSR (see link above) provides tools that leverage these 'annotations' (runtime instrumentation, static checker, documentation generation). All the tools works at the MSIL level and, thus, are language agnostic. Code Contracts should work for any .net language (module bugs in the decompiler).

 

In the future, it will be up to the language designers to integrate contracts, similarly to the foreach statement in C#.

Or provide guarantees at the type-level, such that when a particular value is constructed, it is checked that certain properties hold thereafter, e.g. int -> nat. Why should you have to duplicate assumptions about a type when it can be encoded in the type itself.

type nat = int x where x >= 0;

type defined<t> = t x where x != null; // of course here we'd prefer that defined<t> was the default for all t

This would enable invariants by construction. And some more ideas -

type const<t> = const<t>; //compiler magic, ensures constness (or define at member level via some syntax)

type clean<t> = clean<t>; //compiler magic, ensures purity (no exceptions, etc.)

type pure<t> = transitively<clean<t>>; // transitive compiler magic

I can see this syntax and semantics compile at least partially down to library annotations using System.Diagnostics.Contracts. And it appears somewhat more useful that just pre- and postconditions.

Also

public t pct<t>(t x) where x >= 0 and x <= 100

      ...

In this case we define t in the function definition itself and expect the compiler (compile-time or run-time) to check that x >= 0 && x <= 100 holds for all x of t. This function will also return values of an "anonymous" type t which will have the desirable properties or fail predictably when they break.

And finally

type purecsharp = transitively<clean<csharp>>; // compiler magic that transforms a C# compiler value into a transitively clean C# compiler value; all you do then is write to disk and start using! 

Charles said:

Ion Todirel said:

*snip*

It was a rhetorical question

C

So until it is in the language, do you use a simple framework like this one http://www.codeproject.com/KB/cs/designbycontract.aspx

Or even simpler using if ?

...
public int Exemple
{ 
   set 
   { 
      if (value == null) 
         throw new ArgumentNullException();
       ...
    } 
}
...

Eiffel own the name Design by Contract or all of the concept ?

cro said:

Charles said:

*snip*

So until it is in the language, do you use a simple framework like this one http://www.codeproject.com/KB/cs/designbycontract.aspx

 

Or even simpler using if ?

 

...
public int Exemple
{ 
   set 
   { 
      if (value == null) 
         throw new ArgumentNullException();
       ...
    } 
}
...

 

Eiffel own the name Design by Contract or all of the concept ?

Nope, it's part of .Net Framework 4.0; see the System.Diagnostics namespace for the Contract/s class. Also, you probably don't want to hardwire exception throwing code into your code like that. Contract checking can be turned off at runtime although you can use methods that always check.

Oh sorry, you want it as part of 2008, well then have fun with a 3rd party solution unless you can use the MSR library.

Design by Contract most prominently seen in Eiffel. I believe the term Design by Contract is an Eiffel innovation but some of the ideas probably predate it. Since then you can find some variation of the idea in D, Spec#, Sing# (probably) and others.

exoteric said:

cro said:

*snip*

Nope, it's part of .Net Framework 4.0; see the System.Diagnostics namespace for the Contract/s class. Also, you probably don't want to hardwire exception throwing code into your code like that. Contract checking can be turned off at runtime although you can use methods that always check.

 

Oh sorry, you want it as part of 2008, well then have fun with a 3rd party solution unless you can use the MSR library.

 

Design by Contract most prominently seen in Eiffel. I believe the term Design by Contract is an Eiffel innovation but some of the ideas probably predate it. Since then you can find some variation of the idea in D, Spec#, Sing# (probably) and others.

(to add to Exo) You can use the devlabs contracts, but sadly - presently at least - code contracts will not gain traction, consequent to the full features being only available to Visual Studio Team System.

Apparently Microsoft think that only Visual Studio team system developers want to build robust code - the rest of us like creating leaky code full of null checks. If you have the time or willingness then please vote at connect.

If you really want to understand code contracts, then Charles has one of my favorite ever interviews going on about sleeping barbers on Channel 9 with Bertrand Meyer. It's ad-hoc, unscripted and deeply enlightening. Make you see just how slow the world of programming tends to really move, and what the result of being passionate about something (like contracts) results in.

vesuvius said:

exoteric said:

*snip*

(to add to Exo) You can use the devlabs contracts, but sadly - presently at least - code contracts will not gain traction, consequent to the full features being only available to Visual Studio Team System.

 

Apparently Microsoft think that only Visual Studio team system developers want to build robust code - the rest of us like creating leaky code full of null checks. If you have the time or willingness then please vote at connect.

 

If you really want to understand code contracts, then Charles has one of my favorite ever interviews going on about sleeping barbers on Channel 9 with Bertrand Meyer. It's ad-hoc, unscripted and deeply enlightening. Make you see just how slow the world of programming tends to really move, and what the result of being passionate about something (like contracts) results in.

Eiffel is adding null-safety to the language (called void-safety in Eiffel), see this paper

http://bertrandmeyer.com/tag/void-safety/

I also don't like having contracts everywhere saying requires(x != null) for example.

I'd rather like to see Nullable<Employee> and statically enforce consuming code to check for nullness before consuming the value - like staticaly enforcing pattern matching on ADTs.