If I had pre- and postconditions on all of my methods that interface with the user (dom-events etc) and that manipulated data I would KNOW where the bug FIRST occurred, where the bug IS, not just where it became noticeable, where it caused hours of work to be lost by the client.

or a special inline documentation field
/**
* @contract-start
* expectNumber(a);
* @contract-end
*/

function foo(a, b) {
/* DEBUG BEGIN */
// checks here
/* DEBUG END */
// normal body of function for production
}

The advantage this does have over unit testing is that unit tests will by definition never run under the intended conditions, in a browser with a stupid user doing all sorts of things he is not supposed to do, request timing out, connection failing etc..

Code contracts on the other hand CAN, they can be in effect under normal usage and can help identify all the small things that you never ever imagined could happen – like a function that returns .childNodes[0] of some div suddenly returns a textnode instead of the DIV you KNOW is there, wtf?

I would prefer an interface that’s a little more fluent like:


Contract.expectNumber (a, 'a')
.expectNumber (b, 'b')
.expectWhen(config.mode === "divide", b> 0, "Divisor cannot be 0")
...


I prefer unit testing, TDD to be exact because your test code is separated into its own file, no need to write a tool to remove all this, or extensive commenting out.

My 2 cents.

The ContractErrors will also be extended so that they better explain which condition failed.

I’m thinking also to have an option to insert timing statements, try/catch blocks with a specified error handler – bundled with tools like http://eriwen.com/javascript/js-stack-trace/ and proper error reporting this can really help improve code quality.

How many pieces of code doesn’t rely on ‘magic’ to work? (and by magic I mean undefined values, “” being evaluated as boolean false, “false” and “true” as true, undefined as boolean false, numbers being passed as strings etc … )

@ywg
With unit testing you are only testing the code with known inputs and checking for the correct output. With code contracts you can put code in real use (for instance as a beta) and with proper error handling you will detect the areas where the input is not properly guaranteed for due to browser quirks etc

Other than that, during development it both serves to document your code, it does input validation and it helps you implement complex functions by explicitly stating the contract that it must comply with.

I know firsthand that when writing javascript applications with >20k lines you will never be able to really guarantee that the input (from browser events, etc) will be valid, and at all conditions are met.