With a contract-checking facility (CCF) eventually becoming a part of the C++ language and macro-based CCFs being readily available (e.g., in GSL), it is crucial that we have guidelines for the proper application of contract-checking to avoid their becoming a proverbial hammer with everything looking like a nail! In this talk, we aim to articulate solid principles allowing us to identify scenarios that contract checking is designed (and/or is able) to address. What's more, we'll examine "potential use cases” where using a CCF might seem like a great idea, but in reality it would be a grave mistake to do so. With these principles and a variety of examples on both sides of the fence, we hope to assist attendees in developing a strong intuition for the proper use of contracts (and a CCF to check them) in their own projects.
After a brief review of the capabilities (rather than syntax) of a typical contract-checking facility, we will look into its primary purpose: to help improve the robustness of code written with narrow contracts (i.e., those having preconditions). This review will organically lead to the two core principles of contracts checking: (I) in a defect-free program, function contracts should never be violated, and (II) whether any given aspect of a contract is checked should make no observable (meaningful) difference except, perhaps, runtime performance. With this principles in mind, we will look at a variety of real-world, practical examples where the (sometimes essential) behavior of the program would change should a contract-checking statement be removed. In particular we will see why using any CCF for input validation is wrong-minded. Along the way, we’ll take a nuanced look at why careful use of a CCF for some important real-world use cases that technically violate the letter of these guidelines, might still be in keeping with their spirit, and thereby admit (principled) practical use of a CCF in controlled deviations from what would otherwise be considered text-book best practices.
