Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite
1

What benefits does having code contracts available within the language/framework have? How does it compare to using unit tests or assertions instead?

share|improve this question
2  
I've never heard the term "code contracts". Are you referring to Design by Contract? – Thomas Owens♦ Sep 6 '10 at 21:47

closed as not constructive by MichaelT, Kilian Foth, thorsten müller, Bart van Ingen Schenau, Jalayn Apr 17 at 12:42

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

1 Answer

up vote 2 down vote accepted

At the moment, code contracts are not very useful compared to unit tests and similar mechanisms. The technology and the research is not quite there yet to enable fast and reliable compile-time static checking of contracts.

However, I expect this to change. I expect that by 2020 we will have static analysis tools that will successfully enforce code contracts and flag all violations with a compiler error. Eventually code contracts will become part of beginners’ introductions to programming.

However, personally I don’t think code contracts by themselves will replace unit tests. Maybe something else in conjunction with code contracts will, but not code contracts by themselves. Code contracts can only ensure certain properties about the code, but not semantic correctness. (Nor can unit tests, but together the two will catch more errors than one alone.)

share|improve this answer
1  
We can't flag all violations of a contract (have you heard of the halting problem)? – Casebash Sep 6 '10 at 23:03
I'm familiar with DbC, but I fail to see how specifying preconditions, postconditions, and invariants have anything to do with the halting problem. – Thomas Owens♦ Sep 7 '10 at 2:47
1  
@Casebash, Thomas is right. There is nothing in code contracts per se that requires solving the halting problem. Of course you could invent code contracts that do (the obvious one being “this method will return”). Besides, even if you did have such code contracts, you could still flag them wherever the solver can’t prove that it will halt. Even if it throws some false alarms, that’s still worlds better than no static checking at all. – Timwi Sep 7 '10 at 3:45
Many useful code contracts will be equivalent to the halting problem. Some won't. For example, const in C++ – Casebash Sep 7 '10 at 5:01
@Casebash Again, const has nothing to do with DbC. There are three components. The precondition describes the valid inputs to the method, the postcondition describes the changes made to the system or subsystem (usually a class in OO languages using DbC) during execution of the method, and the invariant describes what hasn't changed during the execution of the method. – Thomas Owens♦ Sep 7 '10 at 10:11
show 2 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.