I just posted Design by Contract for NETMF on Codeshare. Feel free to discuss and make suggestions here.
Is it just by chance that your post directly appears after my post with the attempt to code a driver for the Bluetooth module or is your post just the result of mine? Anyway, I feel caught out and the bugs of not considering important preconditions become obvious. But, testing fulfillment of the known preconditions does not prevent from neglecting preconditions which were not considered to be important.
Thanks for your interesting post.
@ Cuno - Purely accidental
DbC for sure isn’t a panacea. People make about as many mistakes per line of specification as they make per line of code. For example, as you said, by not thinking of all the preconditions that apply.
On the other hand, it is rarely practical to test completely and precisely all preconditions. It takes a bit of practice to achieve a good balance. For example, I usually test string parameters only for null and not-empty conditions, rarely for the exact string syntax that I expect. It depends a lot on where I expect the caller to make mistakes and how difficult to diagnose they would be. Also, I never have loops in my precondition checks. As a result, the checks don’t cost me much in terms of speed or code size, but still catch a large percentage of the mistakes that I make. The old 80/20 rule applies: 80% of benefit for 20% of the cost, compared to a “pure” approach that tries to express 100% of the preconditions. Ah, and precondition checks appear to be quite a bit more relevant in practice than postcondition and invariant checks.