Code contracts, do you use them?
-
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
Quote:
It tells you when you have broken the contract.
But it also tells you it's busted, when in fact it's not busted, right? (Don't you get the error even if you've initialized a readonly variable to a guaranteed non-null value?) I know for certain this wasn't working last year, but maybe they've fixed it. If so, cool
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
Quote:
It tells you when you have broken the contract.
But it also tells you it's busted, when in fact it's not busted, right? (Don't you get the error even if you've initialized a readonly variable to a guaranteed non-null value?) I know for certain this wasn't working last year, but maybe they've fixed it. If so, cool
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Judah Himango wrote:
But it also tells you it's busted, when in fact it's not busted, right?
Not with a dynamic check. The static check will tell you it's busted, but the dynamic check actually checks the condition at runtime.
*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:
But it also tells you it's busted, when in fact it's not busted, right?
Not with a dynamic check. The static check will tell you it's busted, but the dynamic check actually checks the condition at runtime.
*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
Right. That's what I'm saying. If you use the tool, it gives you too many false positives. You solved that by turning off half the tool: turning off static analysis.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
Right. That's what I'm saying. If you use the tool, it gives you too many false positives. You solved that by turning off half the tool: turning off static analysis.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Well, I have used the static analysis in the past, and combined this with Pex and Moles. It was certainly enlightening. But yes, I turn static analysis off - I've been saying that right from the start here.
*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
-
Well, I have used the static analysis in the past, and combined this with Pex and Moles. It was certainly enlightening. But yes, I turn static analysis off - I've been saying that right from the start here.
*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
Got it. We must have been talking past each other.
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
It tells you at runtime that you called a method with an invalid argument. That is really no different from "if(x == null) throw new ArgumentException("...")", except that anyone who sees that code will go 'huh? What is Contract.*?' and it's an extra piece of learning required for very little benefit.
-
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 take contracts out on my coworkers when they fail to meet the contracts specified by the interfaces between our respective parts of the product. Does this count?
Software Zen:
delete this; -
It tells you at runtime that you called a method with an invalid argument. That is really no different from "if(x == null) throw new ArgumentException("...")", except that anyone who sees that code will go 'huh? What is Contract.*?' and it's an extra piece of learning required for very little benefit.
BobJanova wrote:
That is really no different from "if(x == null) throw new ArgumentException("...")",
Superficially, you're right. If that's all that contracts did, I wouldn't bother with them. However, they provide some really handy ways to do this as I specify here[^] and here[^]. Invariants and Abbreviators are very handy, but the ability to provide contracts for interfaces is the cherry on the cake as far as I'm concerned.
*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
-
BobJanova wrote:
That is really no different from "if(x == null) throw new ArgumentException("...")",
Superficially, you're right. If that's all that contracts did, I wouldn't bother with them. However, they provide some really handy ways to do this as I specify here[^] and here[^]. Invariants and Abbreviators are very handy, but the ability to provide contracts for interfaces is the cherry on the cake as far as I'm concerned.
*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
Honestly that all looks horrible and hacky ... and particularly if it is rewriting the IL underneath me I want no part of it. An 'abbreviator' can be written in normal code just fine, it's simply a validation method! Interfaces that are exposed to external APIs to implement are about the only place where I can see that postcondition validation would be useful. But since you can't force external providers to use contracts, it doesn't help you there anyway! Postconditions in general (and invariants are simply a postcondition applied to everything) shouldn't be necessary in your code because you should already know what your code is doing, and each particular operation can be tested. If you need a global postcondition then you can have a method in your test class that checks that part of the state, which you can call in each relevant test.
-
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. 2. Yes for interface members and abstract members, where the actual logic is going to be implemented in an implementation. Occasionally on a concrete member if the logic is not straightforward and there are specific conditions that are reasonably verifiable. 3. Yes, I use the Contract class. 4. No.
-
Honestly that all looks horrible and hacky ... and particularly if it is rewriting the IL underneath me I want no part of it. An 'abbreviator' can be written in normal code just fine, it's simply a validation method! Interfaces that are exposed to external APIs to implement are about the only place where I can see that postcondition validation would be useful. But since you can't force external providers to use contracts, it doesn't help you there anyway! Postconditions in general (and invariants are simply a postcondition applied to everything) shouldn't be necessary in your code because you should already know what your code is doing, and each particular operation can be tested. If you need a global postcondition then you can have a method in your test class that checks that part of the state, which you can call in each relevant test.
I'm not trying to force you to use them. If you want to remain doing if/then checking then that's fine. And if you use the interface technique, you do force them to use the contracts.
BobJanova wrote:
Postconditions in general (and invariants are simply a postcondition applied to everything) shouldn't be necessary in your code because you should already know what your code is doing,
Indeed you should, but what happens three years down the line when you've left the company and young Harry Intern takes a shot at your code? Oh, and he doesn't run unit tests.
*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 am quite sure I missed somthing about the concept of contracts: Violation of contracts cause exceptions, exactly like violation of using code which is not designed to work with values without the corresponding contract with the drawback of splitting location of need of assumption. What are your reasons for using contracts?
-
I am quite sure I missed somthing about the concept of contracts: Violation of contracts cause exceptions, exactly like violation of using code which is not designed to work with values without the corresponding contract with the drawback of splitting location of need of assumption. What are your reasons for using contracts?
stefan seeland wrote:
Violation of contracts cause exceptions, exactly like violation of using code which is not designed to work with values without the corresponding contract with the drawback of splitting location of need of assumption.
What are your reasons for using contracts?Well, let's say you have a function that takes two numbers, persists them somewhere (maybe updating its own class' field values) and then returns the division result:
double Divider(double n, double d) { Persist(n, d); return n/d; }The difference, with testing the parameter values first, is that you avoid the issue that something in the object's state (or some other system's state) has changed. Another example - if you could check every SQL transaction before executing it, then there wouldn't be any need for transactions and their accompanying rollbacks. MarcReverse 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:
bookmarked for later
And, again, "later" will never come :-O
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
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:
guaranteed non-null value and cannot be reassigned due to the readonly modifier
FALSE. http://stackoverflow.com/questions/7876333/modify-private-readonly-member-variable[^] and as i'm a CPian: Internals of Constants and Readonly[^]
Quote:
Please note that you can't declare it in any of the methods or ctors because, throughout your class instance life time, the readonly variable should be known and so its value. Hence it is declared in class scope and defined there itself or at object construction AKA ctor. But you can bypass this rule via reflection.
What if someone is crazy enogh to do this?
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
Judah Himango wrote:
guaranteed non-null value and cannot be reassigned due to the readonly modifier
FALSE. http://stackoverflow.com/questions/7876333/modify-private-readonly-member-variable[^] and as i'm a CPian: Internals of Constants and Readonly[^]
Quote:
Please note that you can't declare it in any of the methods or ctors because, throughout your class instance life time, the readonly variable should be known and so its value. Hence it is declared in class scope and defined there itself or at object construction AKA ctor. But you can bypass this rule via reflection.
What if someone is crazy enogh to do this?
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
You're being pedantic. Of course you can crack open the hood and fiddle with the members via reflection, but you could break all sorts of contracts that way, particularly invariants. In the same vein, you can use reflection to modify strings, which are supposedly immutable! Imagine all the havoc you could wreak... But that's not really helpful. In practice, readonlys are readonly. :)
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
It will, next time I work on a specific product, I'm always looking for ways to make the code for it cleaner since I've written all of it so far and it all reflects on my ability. (But normally you'd be right ;P )
i'll look at it now, i liked the idea, but this post came literally 5 minutes before i leave the work :laugh:
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
You're being pedantic. Of course you can crack open the hood and fiddle with the members via reflection, but you could break all sorts of contracts that way, particularly invariants. In the same vein, you can use reflection to modify strings, which are supposedly immutable! Imagine all the havoc you could wreak... But that's not really helpful. In practice, readonlys are readonly. :)
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
sorry if i sounded offensive, i posted that while trying to shut off the pc to get home :laugh: i was just pointing out that you should never trust the integrity of your data, even the internal readonly one. unless you are the only developer and the software will be used only internally, you can't assume no one will try to modify your internal data. BUT, for library code, you should never use private readonly anyway, i've had to much trouble with the MVC 3 model binder error messages on unobtrusive validation to know that ;P
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
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#Unit testing is for the weak. I prefer Chuck Norris style :rolleyes:
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia