From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Charles Hixson Subject: Re: Software landmines (loops) Date: 1998/09/09 Message-ID: <35F712BD.4F521172@earthlink.net>#1/1 X-Deja-AN: 389568621 Content-Transfer-Encoding: 7bit References: <35f51e53.480 <904556531.66622 <6t4dmi$rhp@flatland.dimensional.com> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: Wed Sep 9 16:42:09 1998 Organization: Mandala Fluteworks Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-09T00:00:00+00:00 List-Id: Jim Cochrane wrote: > > Of course, if the conditions being checked in the code below are really > pre-conditions - that is, it can be considered a coding error that the > function is called with one of these conditions true, then it would be > better coded as: > > void Worker::do_something (Tree *top) > { > assert (top != NULL && top->child != NULL && ...); > > _error_code = really_do_something(top->child...->child); > if (_error_code != 0) // or whatever value means non-error > { > _error_occurred = true; > } > else > { > _error_occurred = false; > } > } > > Where the assertion would be documented as a pre-condition of the function > specification. > > Then a client would do: > > // ensure the pre-condition for root > worker.do_something (root); > if (worker.error_occurred()) > { > //report/handle the error with worker.error_code() ... > } > > [Changed to an OO style, since the discussion is occurring on OO > newsgroups.] > > The difference, of course, is that the checking for null pointers becomes > part of the function specification rather than being explicitely coded (the > assertion will probably be turned of in the production release). This is > the difference between design by contract and defensive coding. > ... > -- > Jim Cochrane > jtc@dimensional.com It has been claimed that Design By Contract (DBC) can be done entirely by comments and documentation. I, personally, don't believe it. It is my expectation that the routines with explicit pre-conditions and post-conditions would work as desired in the Eiffel environment, where the developer could have pre-conditions enabled while developing it, and only remove them (IN LAYERS!) when the final code was produced. I don't think that this would work at all as well without support from the IDE. Now it is true, that the failures of DBC in an environment that doesn't support it can be traced to the contract not being lived up to, but ENFORCEABILITY IS A PART OF THE CONTRACT. In an environment that doesn't enforce the contract, violations will not be detected, and I don't know about you, but my programs always need to have the bugs cleaned out of them before they are ready for delivery.