Xref: utzoo comp.misc:5358 comp.lang.misc:2703 Path: utzoo!attcan!uunet!mcvax!kth!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.misc,comp.lang.misc Subject: Re: Program Errors and developement environment Message-ID: <4352@enea.se> Date: 2 Mar 89 22:42:14 GMT Organization: ENEA DATA AB, Sweden Lines: 85 Stanley Chow (schow@bnr-public.UUCP) writes: > How many of these error can be (are) prevented/encouraged by the > language (implementation and specification), O/S, developement > environment that you use? > > How much cost saving (time & money) could be achived if an environment > prevents all of these problems? What problems would remain? >M.R.Murphy (mrm@sceard.UUCP) writes: >> 1) Is the argument count correct? Can occur with languages with a weak module concept like C and Fortran. But are also likely to occur with routines with variable parameter lists like for instance VMS system calls. Gain: Variable parameter lists gives flexibility. Loss: Harder to detect mistakes. More likely that error causes a crash in a live system. >> 2) Is the spelling correct? Occurs with totally interpreted languages like DCL or MUMPS. Gain: Enormous strength for referencing by string manipulation. Loss: Unbearable for somewhat big programs. I've just condluded 300 lines of DCL what would have been longer in a compiled langauges. But to test it takes longer time. >> 3) Is the argment type correct? Occurs with untyped or weakly typed langauges like C, Pascal and Lisp(?). Gain: Higher flexibility when you really have multi-type arguments. (Not with Pascal.) In many applications no gain at all. Loss: Errors are detected later and will be more expensive. >> 4) Is the variable initialized correctly? Occurs with most langauges. Some langauges (e.g. Eiffel, Simula) defines intial values which saves when the correct initial values is the same as the one of the langauges. Also, it gives the erroneous program as a less random appearance. (Works sometimes, sometimes not.) Although assert statements and similar can help, this is mainly a programmer issue. >> 5) Do "ends" match "do"s? Occurs only in interactive langauges. Simple but fatal errors you don't want be afraid to have in your 200000-line system. >> 6) Is the correct register used? Seems like an assembler-only problem. >> 7) Is a previous equate, using, or define in effect? Given as C problem, but similar can occur in any block-oriented language with a WITH or USE statment. Often convenient for short notation. Problem when over-used. >> 8) Is the level of indirectness correct? Sounds like something that would happen with assembler or maybe C. And, yeah, DCL too. But the levels should never be that many one one step. More like a programmer issue. >> 11) Is the index out of range? Any langauge that allows you to turn off index checks, which means all. Gain is better performance Loss is strange-behaving programs. >> 12) Is reentrancy, reusability, refreshability preserved? Reusabililty at least requires flexibility and modularity. Pascal is a real loser here. Ada and Eiffel and winners. >> 13) Did you let something go by that you can't explain? Fix it now. >> 14) Does the program have anything remotely to do with the requirement >> for the program? >> 15) Did you start to code before thinking? >> 16) Did you read the manual? Programmer issues to most part. Important nevertheless. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se