New article: contracts in practice
For almost anyone programming in Eiffel, contracts are just a standard part of daily life; Patrice Chalin’s pioneering study of a few years ago [1] confirmed this impression. A larger empirical study is now available to understand how developers actually use contracts when available. The study, to published at FM 2014 [2] covers 21 programs, not just in Eiffel but also in JML and in Code Contracts for C#, totaling 830,000 lines of code, and following the program’s revision history for a grand total of 260 million lines of code over 7700 revisions. It analyzes in detail whether programmers use contracts, how they use them (in particular, which kinds, among preconditions, postconditions and invariants), how contracts evolve over time, and how inheritance interacts with contracts.
The paper is easy to read so I will refer you to it for the detailed conclusions, but one thing is clear: anyone who thinks contracts are for special development or special developers is completely off-track. In an environment supporting contracts, especially as a native part of the language, programmers understand their benefits and apply them as a matter of course.
References
[1] Patrice Chalin: Are practitioners writing contracts?, in Fault-Tolerant System, eds. Butler, Jones, Romanovsky, Troubitsyna, Springer LNCS, vol. 4157, pp. 100–113, 2006.
[2] H.-Christian Estler, Carlo A. Furia, Martin Nordio, Marco Piccioni and Bertrand Meyer: Contracts in Practice, to appear in proceedings of 19th International Symposium on Formal Methods (FM 2014), Singapore, May 2014, draft available here.
Eiffel Software
Home page at ETH
Informatics Europe
LASER summer school
Propulsion Academy
After more than three years of Eiffel development, we find (anecdotally):
* Initial-code first, follow with contracts, follow with testing to exercise the code and contracts. This yields time to solidify a feature or set of features design. Be prepared to walk this cycle several times until all contracts have been exhaustively thought of (as far as one can know at any one moment).
* Do “Contract Reviews”. This is both self-review and peer-review. Use the time to ensure tests have been written to exercise the code and contracts directly or indirectly. Pay attention to not only contract coverage, but test coverage along this path.
* Be prepared to spend a great deal of time in running all tests and fixing broken tests before checking code in.
* Resist the initial urge to not contract or not test. Over time, having both builds confidence in the code base at large.
* Indulge yourself in writing small libraries of your own instead of building one massive code base. This will isolate code, contracts, and testing making the process more manageable. NOTE: This is not a violation of “be a library consumer before being a library builder.” Your libraries will not (at first) be fodder for public consumption. However, writing your code-base in libraries will help keep problems isolated and testing time down. You will know that code is impacted because it becomes corralled in a library. To this end, think about your class naming conventions with your own little-library names baked in.
Over time you will get to not only like and love contracts in your code, but you will come to depend on them and even think about your code with them. This means you can exclude a host of possibilities when contemplating bugs because you know you’ve written contracts to cover various contingencies. Without contracts, your mind is free to wander and wonder, leaving the only way to “prove it” is to run and hand-test, which is labor intensive.
* Well-contracted code is less-buggy-code because you prove it each time you test and run. This ought to provide more desire to write contracts, which is the opposite of a vicious circle.