Code contracts, do you use them?
-
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
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# -
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
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# -
#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
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 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# -
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#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
-
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
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# -
Thanks, the article looks pretty in depth (only skimmed it for now, but it's bookmarked for later) :thumbsup:
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
Contractclass. MarcReverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
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#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
-
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#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
-
-
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
Judah Himango wrote:
The problem with Code Contracts is three-fold:
Wow. Thank you for the detailed explanation! That provides some really valuable counterpoint. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
-
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
Pete O'Hanlon wrote:
I lap up the attention.
Well, here's[^] your opportunity for more attention. :) Seriously though, I was wondering what your thoughts were on Judah's post - it seems like he brings up some significant issues. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
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
Judah Himango wrote:
- 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:
This should only happen if you're doing static checking. If you do runtime checking, you only see the contract checks, so the example you quote won't trigger anything. What I would expect to see here is (assuming that we can only call
DoSomethingafter it's had some data added into it).*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
-
-
Pete O'Hanlon wrote:
I lap up the attention.
Well, here's[^] your opportunity for more attention. :) Seriously though, I was wondering what your thoughts were on Judah's post - it seems like he brings up some significant issues. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#I've added my thoughts to that post - and introduced the caveat of thread safety with contracts.
*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 Himango wrote:
- 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:
This should only happen if you're doing static checking. If you do runtime checking, you only see the contract checks, so the example you quote won't trigger anything. What I would expect to see here is (assuming that we can only call
DoSomethingafter it's had some data added into it).*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
Sure, if you turn off static checking, you don't get any compiler warnings. In that sense, it's hardly better than
if (foo == null) throw new...What I would expect to see is:
public void DoSomething()
{
Contract.Requires(list != null);
}Why would you expect to see a list null check? List is initialized at declaration to a guaranteed non-null value and cannot be reassigned due to the readonly modifier.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
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#Marc Clifton wrote:
1. Do you routinely verify the expected parameter values that your method receives?
Only at layer boundaries via the classes that are exposed that way.
Marc Clifton wrote:
2. Do you verify post-conditions (you're method is returning something correct)?
No. I do however verify results from other layers.
Marc Clifton wrote:
3. Do you use the Contract class, or are you happy with Debug.Assert... and its variants?
No and no. If I verify something then it remains part of the code.
Marc Clifton wrote:
4. Do you use your own variant, something like the Contract class?
Not any more. I wrote one one time but it just isn't worthwhile.
-
Sure, if you turn off static checking, you don't get any compiler warnings. In that sense, it's hardly better than
if (foo == null) throw new...What I would expect to see is:
public void DoSomething()
{
Contract.Requires(list != null);
}Why would you expect to see a list null check? List is initialized at declaration to a guaranteed non-null value and cannot be reassigned due to the readonly modifier.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Judah Himango wrote:
Why would you expect to see a list null check?
And what happens if someone modifies the code and removes the initialisation of the list? As far as turning off the static checking - contracts allow you to do so much more that they do add value beyond simple
if (...)checking, even if that ultimately is what they produce. For example, object invariant contracts are useful if your class has state that must conform to a particular requirement - invariants are automatically rewritten into your code to make sure you don't break the state. If you have checks that you do regularly in a class, then use an abbreviator. And yes, you've pointed out that you have to write a dummy class for interface checking, but it has saved our bacon quite a few times with our interfaces by allowing us to supply APIs to the client that do the checking for them when they implement one of our interfaces - that's a real timesaver.*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 Himango wrote:
Why would you expect to see a list null check?
And what happens if someone modifies the code and removes the initialisation of the list? As far as turning off the static checking - contracts allow you to do so much more that they do add value beyond simple
if (...)checking, even if that ultimately is what they produce. For example, object invariant contracts are useful if your class has state that must conform to a particular requirement - invariants are automatically rewritten into your code to make sure you don't break the state. If you have checks that you do regularly in a class, then use an abbreviator. And yes, you've pointed out that you have to write a dummy class for interface checking, but it has saved our bacon quite a few times with our interfaces by allowing us to supply APIs to the client that do the checking for them when they implement one of our interfaces - that's a real timesaver.*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
Pete O'Hanlon wrote:
And what happens if someone modifies the code and removes the initialisation of the list?
Then I would expect the contract checker to tell me it's busted. A boon of this tool should be: "tell me when my code is busted." The current state of this tool is: "your code is busted, even if it isn't!"
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
Pete O'Hanlon wrote:
And what happens if someone modifies the code and removes the initialisation of the list?
Then I would expect the contract checker to tell me it's busted. A boon of this tool should be: "tell me when my code is busted." The current state of this tool is: "your code is busted, even if it isn't!"
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Judah Himango wrote:
Then I would expect the contract checker to tell me it's busted.
And that's exactly what my example does. It tells you when you have broken the contract.
*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
-
I've added my thoughts to that post - and introduced the caveat of thread safety with contracts.
*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
Pete O'Hanlon wrote:
I've added my thoughts to that post - and introduced the caveat of thread safety with contracts.
Fascinating! And thank you! Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
Pete O'Hanlon wrote:
I've added my thoughts to that post - and introduced the caveat of thread safety with contracts.
Fascinating! And thank you! Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#You're welcome mate. Glad to be of service.
*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
