On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote:
> Runtime checks: data validation & code validation
> Compile-time checks: code validation
>
> What sort of data validation is appropriate for assert statements or
> contacts that may be skipped due to trading performance for more risk
> ('optimized out')?
That depends on what you mean by "data validation".
Testing for bad input, or testing for predictable error states such as
I/O errors, missing files, permission errors, server down etc is
not appropriate for assertions (which includes contracts).
The rule I use is that assertions are for:
(1) testing your program state, which is under your control; and
(2) communicating the intention of your program as executable
code rather than comments.
The ultimate aim of contracts and assertions is to eventually disable
them when the program is bug-free.
The Eiffel docs say:
It should be clear from the preceding discussion that contracts
are not a mechanism to test for special conditions, for example
erroneous user input. For that purpose, the usual control
structures [...] are available [...] An assertion is instead a
correctness condition governing the relationship between two
software modules (not a software module and a human, or a
software module and an external device). ... Bluntly:
Rule -- Assertion Violation: A run-time assertion violation is
the manifestation of a bug.
https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions
For detecting *external* error states (anything to do with data that
comes from outside your program, like user input) you can never let your
guard down and never disable the test, because servers can always go
down, users can always give you bad data, files can always be corrupt.
It is unsafe to disable these tests and so these should not be
assertions.
For a library function intended to be called by third-parties, the
function arguments aren't under the control of the library author so
should not be tested with assertions. But for an application where the
author controls those function arguments, they are under the author's
control and may be assertions or contracts.
Design By Contract is partly a methodology and partly a set of syntax.
Its a way of thinking about the design of your program. In practice, you
don't have to buy 100% into DBC to get some benefit for it. A study done
a few years back looked at 21 large projects in Eiffel, JML (Java) and
Code Contracts for C# and found that 33% of the classes used contracts.
http://se.ethz.ch/~meyer/publications/methodology/contract_analysis.pdf
Like unit testing, you don't need 100% coverage to get benefit. 10% is
better than nothing, and 20% is better than 10%.
I wrote more about assertions here:
https://import-that.dreamwidth.org/676.html
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
