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=0.7 required=5.0 tests=BAYES_00,INVALID_MSGID, PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public From: jtc@dimensional.com (Jim Cochrane) Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <6sleir$btk@flatland.dimensional.com>#1/1 X-Deja-AN: 387404596 References: <9qnQhDAAvZ71EwAx@radm.demon.co.uk> <6skh4n$491@flatland.dimensional.com> Organization: Dimensional Communications NNTP-Posting-Date: Thu, 03 Sep 1998 00:56:38 MDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-03T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >jtc@dimensional.com (Jim Cochrane) writes: > >> You are correct. My premise was a bit off. A better one would be: >> Before implementing a routine, it is necessary to determine what the >> routine must accomplish. A very effective method of doing this is to >> document the specification for the routine in the form of pre- and >> post-conditions. Once this is done, the routine can be coded such that it >> meets the post-condition based on the pre-condition. > >There may be a misunderstanding here. In my stack equality example, >there were NO precoditions. > Um, yes, there is a misunderstanding :-). I was responding to someone who was resonding to a previous post of mine, which was commenting on someone else's response to an example posted by Robert Martin. That is, the code being discussed is Robert's code, in which he forgot to deal with the fact that the two containers could have different sizes (number of elements). >I think that the check > > if L.Top /= R.Top then > return False; > end if; > >was (incorrectly) interpreted as some kind of precondition check. But >this interpretation is incorrect. > >This fragment means, if the stacks don't have the same depth, then they >aren't equal. > >> In the quoted example, documenting the pre-condition would have helped to >> uncover the fact that containers of different sizes would need to be dealt >> with. > >In my original example, there weren't any preconditions. > >> It would become obvious that a pre-condition of l.size = r.size >> would not be appropriate and thus that the negation of this condition would >> need to be dealt with in the implementation. > >The stacks I was comparing in my example all had the same (max) size. >The check I was making was for different depths. At the risk of adding more confusion, by l.size ... I meant the number of elements in l, not the maximum size - and again, this was discussing a code snippet that Robert Martin had posted. Sorry for the confusion. -- Jim Cochrane jtc@dimensional.com