Code contracts, do you use them?

Marc Clifton

In particular, I was just perusing the Code Contracts[^] class in .NET 4 / 4.5, so I thought I'd take a quick survey of the community: 1. Do you routinely verify the expected parameter values that your method receives? 2. Do you verify post-conditions (you're method is returning something correct)? 3. Do you use the Contract class, or are you happy with Debug.Assert... and its variants? 4. Do you use your own variant, something like the Contract class? Just curious. :) Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Pete OHanlon

1, 2 and 3 - yes. 4 - used to.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Ravi Bhavnani

#1 and #3 all the time. I use Debug.Assert() to validate incoming parameters of internal and private methods, and throw ArgumentException in the case of failing public and protected virtual methods (i.e. APIs my clients can call). /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

lewax00

I didn't even know that existed. I'll probably use it now.

OriginalGriff

#1 & #2 yes - #3 & #4 no because I'd not heard of them. Gets my five for something new to me, and I'll have a look in more detail later.

Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

BobJanova

1. Yes, for externally visible access points (property setters, public methods and constructors) if it matters – it's surprising how rarely it seems to matter in the real world, though. Most variables are constrained only by the type you choose for them. 2. This is what unit tests are for. I don't put checks inside the code. You're in full control of what you return, so there's no excuse for it being 'incorrect'. 3. I use a unit testing framework and whatever assertions it provides, not in-code assertions. 4. No

Marc Clifton

Pete O'Hanlon wrote:

4 - used to.

Any reason you stopped? And thanks for the reply! Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Marc Clifton

Cool, thanks for the reply! (BTW, I'm impressed that you take the time to highlight your code pieces!) Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Pete OHanlon

Because we started using MS Code Contracts. We talked about them before[^].

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Marc Clifton

lewax00 wrote:

I didn't even know that existed. I'll probably use it now.

:cool: For further reading: Contracts[^] - this has moved out of the "research" dept. and into .NET 4 and 4.5 I liked this article.[^] Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Marc Clifton

OriginalGriff wrote:

Gets my five for something new to me, and I'll have a look in more detail later.

:cool: and thanks! Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Marc Clifton

BobJanova wrote:

This is what unit tests are for. I don't put checks inside the code. You're in full control of what you return, so there's no excuse for it being 'incorrect'.

Agreed, though there seems to be an interest / suport for post conditions: Postconditions have been harder to express until now, but this attitude is likely to encourage their enforcement in release builds too: a guarantee that the method really will never silently return a value that the contract forbids or leave the object in an invalid state. Source[^] Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Marc Clifton

Pete O'Hanlon wrote:

Because we started using MS Code Contracts. We talked about them before[^].

hahahaha! Just call me Emu (the bird apparently has no memory of the previous day's events.) I certainly didn't remember that. Thank you for the link! Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Pete OHanlon

And I thought you hung on my every word: Article 1[^] and Article 2[^]

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

lewax00

Thanks, the article looks pretty in depth (only skimmed it for now, but it's bookmarked for later) :thumbsup:

Vark111

1. Yes, I routinely check inputs when the inputs matter, which is not always the case. 2. In some cases, usually the higher levels in the architecture will do more post-condition checking, as they tend to be aggregating lower-level results. 3. Don't use Code Contracts. I'm happy with if(condition) throw new... 4. see 3

Marc Clifton

Pete O'Hanlon wrote:

And I thought you hung on my every word:

Those two articles are better than anything else I've read on the subject. Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Marc Clifton

lewax00 wrote:

Thanks, the article looks pretty in depth

And Pete's articles (he links to them here[^] are the best I've encountered on the subject of the Contract class. Marc

Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#

Pete OHanlon

Gosh shucks. :-O Who am I kidding? I lap up the attention.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Judah Gabriel Himango

I've tried it, and stopped using it. The problem with Code Contracts is three-fold:

It's a boil-the-ocean proposition. Everything must use Code Contracts (including 3rd party libs!) or you'll drown in false positives.
It lacks language support. This code will give false positives, warning you that list might be a null reference:

private readonly List<int> list = new List<int>();
...
void DoSomething()
{
Console.Write(list.Length);
}

Another example of the pain of no language support is when it comes to declaring contracts on interfaces. You actually have to create a dummy class that implements the interface, then put contracts on that. YUCK!
Poor library support. Most libraries, even the .NET framework itself or its subsets, don't do Code Contracts well, or at all. I remember doing some Silverlight code a year or two ago, and many of the methods were missing obvious contracts.

These things combined result in many false positives. To get rid of those false positives, you must write code to reassure the contract checker that everything's gonna be OK. Not fun. Not worth it. Bottom line: contracts could be great. But it needs broad support from libraries and languages, and that doesn't exist today, and probably won't tomorrow.

My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango