- The errors are found earlier in the development cycle and the cost of correcting them is lesser and the probability of correcting the error correctly is higher.
- While correcting the errors found during computer-based testing, the programmers are under immense pressure forcing them to make more mistakes.
- They involve people including the author and so the program is tested not just by the author but by others.
- The errors found using these processes result in lower debugging costs since the precise nature of the error is located while computer-based testing only exposes symptom of an error.
The author then discusses about code inspections, the breakup of the team, the roles people play and the general procedure. There are two main parts:
- The programmer is requested to narrate statement by statement the logic of the program.
- The program is analyzed with respect to a checklist of historically common programming errors.
The author then provides a common checklist for code-inspection:
- Is an uninitialized variable referenced?
- Is array subscript value within the defined bounds?
- Is array subscript an integer value?
- Is the lifetime of reference variable within the lifetime of referenced storage?
- If a data structure is referenced in multiple procedures or functions, is the structure defined identically in each procedure.
- When indexing into a string, are the limits of the string exceeded?
- Are there any "off by one" errors in indexing operations or in subscript references to arrays?
- Are there any variables with similar names?
- Verify mixed-mode arithmetic correctly.
- Verify different size same data type arithmetic correctly, i.e. long with short.
- Verify divisor not becoming zero in division operation.
- For expressions with more than one operator, are the assumptions about precedence of operators and order of evaluation correct?
- Are operands of a boolean operator boolean?
- Will every loop always terminate?
- Have all files been opened before use?
- Are end-of-file conditions detected and handled correctly?
- Are I/O error conditions handled correctly?
The author then discuss about desk checking and tells that it is not as effective as code-inspection of walkthrough.
The author then talks about peer ratings. The participants are told to evaluate anonymous programs in terms of their overall quality, maintainability, extensibility, clarity and readability. The participants are asked to rate the programs on a scale of 1 to 7 in terms of different questions such as:
- Was the program easy to understand?
- Would it be easy to modify this program?
- Would you be proud to have written this program?
No comments:
Post a Comment