I use DbC occasionally to clarify my thoughts during a refactoring, and then only in the places that continue to make mistakes. In general, I am not in a domain that benefits from DbC.
Contracts are code: More code means more bugs. Declarative contracts are succinct, but difficult to debug when wrong; I believe this because the debugger support for contracts is poor; There is no way to step through the logic and see the intermediate reasoning in complex contracts. A contract is an incomplete duplication of what the code already does: at some level of complexity I prefer to use a duplicate independent implementation and compare inputs/outputs.
Writing contracts cost time and money; and that cost should be weighed against the number and flexibility of the customers that use the code. A one-time script, a webapp for you team, an Android app for your startup, fraud software, and Facebook make different accounting decisions. I contend most code projects can not justify DbC.
On 2018-09-24 03:46, Marko Ristin-Kaufmann wrote:
When you are documenting a method you have the following options:
- Write preconditions and postconditions formally and include them
automatically in the documentation (/e.g., /by using icontract library). 2) Write precondtions and postconditions in docstring of the method as human text. 3) Write doctests in the docstring of the method. 4) Expect the user to read the actual implementation. 5) Expect the user to read the testing code.
There are other ways to communicate how a method works.
6) The name of the method 7) How the method is called throughout the codebase 8) observing input and output values during debugging 9) observing input and output values in production 10) relying on convention inside, and outside, the application 11) Don't communicate - Sometimes <complexity>/<num_customers> is too high; code is not repaired, only replaced.
This is again something that eludes me and I would be really thankful if you could clarify. Please consider for an example, pypackagery (https://pypackagery.readthedocs.io/en/latest/packagery.html) and the documentation of its function resolve_initial_paths:
Resolve the initial paths of the dependency graph by recursively adding |*.py| files beneath given directories. Parameters: *initial_paths* (|List|[|Path|]) – initial paths as absolute paths Return type: |List|[|Path|] Returns: list of initial files (/i.e./ no directories) Requires: * |all(pth.is_absolute() for pth in initial_paths)| Ensures: * |len(result) >= len(initial_paths) if initial_paths else result == | * |all(pth.is_absolute() for pth in result)| * |all(pth.is_file() for pth in result)|
How is this difficult to read,[...]?
This contract does not help me:
Does it work on Windows? What is_absolute()? is "file:///" absolute? How does this code fail? What does a permission access problem look like? Can initial_paths can be None? Can initial_paths be files? directories? What are the side effects?
resolve_initial_path() is a piece code is better understood by looking at the callers (#7), or not exposing it publicly (#11). You can also use a different set of abstractions, to make the code easier to read: UNION(file for p in initial_paths for file in p.leaves() if file.extension=="py")
At a high level, I can see the allure of DbC: Programming can be a craft, and a person can derive deep personal satisfaction from perfecting the code they work on. DbC provides you with more decoration, more elaboration, more ornamentation, more control. This is not bad, but I see all your arguments as personal ascetic sense. DbC is only appealing under certain accounting rules. Please consider the possibility that "the best code" is: low $$$, buggy, full of tangles, and mostly gets the job done. :)