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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: "W. Wesley Groleau x4923" Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/23 Message-ID: <33D6451F.4EB@pseserv3.fw.hac.com>#1/1 X-Deja-AN: 258342114 Sender: usenet@most.fw.hac.com (News Administration) X-Nntp-Posting-Host: sparc02 References: <33D43D93.6A8E@flash.net> Organization: Hughes Defense Communications Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-23T00:00:00+00:00 List-Id: > Consider the aversion of developers to documenting code. It's viewed by them > as a necessary burden which doesn't actually make the software work so there's > little motivation to do it. .... I hope this is not generally true, and I don't think it is. I think that there are far too many that think that way, but OTOH even more just let the documentation slide due to real or perceived schedule pressure. Either way it's a Bad Thing. > little motivation to do it. Executable assertions, OTOH, actually contribute > something (runtime checks) to a running program. Therefore, they have some > material value in the mind of a developer and their more likely to use them. > The by-product is that the code gets documented for free and the developers > actually *want* to do it. And either way, this part is a Good Thing--if it doesn't also slide for the same reasons. > :And what does that do to the oft-said statement that Eiffel programmers > :put in assertions for unlikely events? > > That's what all (or at least most) assertions are. They're catering for the > unlikely event that the developer has made a logic error. Most of the time > we write code with correct logic but occasionally we make mistakes. These > mistakes can often be picked up by an assertion. This is a good idea for most software. But I would think that if you know enough to write the assertion, you know enough to track down and eliminate whatever would make the assertion fail. In safety-critical software, how can you justify not doing so? -- ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be Don't send advertisements to this domain unless asked! All disk space on fw.hac.com hosts belongs to either Hughes Defense Communications or the United States government. Using email to store YOUR advertising on them is trespassing! ----------------------------------------------------------------------