Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ENUXHA.EAS.ASU.EDU!koehnema From: koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) Newsgroups: comp.software-eng Subject: Re: bridge building (was Re: Documenting OO Systems) Message-ID: <9105020234.AA01202@enuxha.eas.asu.edu> Date: 2 May 91 02:34:57 GMT References: <1259@grapevine.EBay.Sun.COM> <9105012313.AA23259@enuxha.eas.asu.edu> <33846@mimsy.umd.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: koehnema@enuxha.eas.asu.edu (Harry Koehnemann) Distribution: na Organization: Arizona State University Lines: 17 In article <33846@mimsy.umd.edu> cml@care.cs.umd.edu (Christopher Lott) writes: > >Let's discuss how we can identify these classes of faults, so we are >able to say before code reviews "watch out for this class of mistakes." >What are the classes of faults which occur most often in your environment? >How expensive are they to identify, fix? (In the previous red herring, >due to the application, pretty darned expensive if missed.) > It's more than that. The point is that the error was not caused by a single programming mistake. It was designed, reviewed, and tested extensively (I hope). Therefore, we must blame th process as being inadequate to catch that type of error. Now, is that type of error less likely to occur in a strongly typed language that strictly enforces well identified software engineering principles (which C does not). I'd say yes. Hell, anyone that uses a break stmt to transfer control out of an if probably needs a little help.