[go: up one dir, main page]

0% found this document useful (0 votes)
47 views2 pages

UI Code Inspection Checklist: Purpose General

The document provides a checklist to guide code inspections of a Java program. The checklist is divided into multiple parts and categories to review various aspects of the code, including initialization, method and class definitions, data reference, computations, control flow, storage, modularity, module interfaces, and input/output. Reviewers are instructed to thoroughly review each category one at a time before moving on to ensure an effective inspection.

Uploaded by

Ravi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
47 views2 pages

UI Code Inspection Checklist: Purpose General

The document provides a checklist to guide code inspections of a Java program. The checklist is divided into multiple parts and categories to review various aspects of the code, including initialization, method and class definitions, data reference, computations, control flow, storage, modularity, module interfaces, and input/output. Reviewers are instructed to thoroughly review each category one at a time before moving on to ensure an effective inspection.

Uploaded by

Ravi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

UI Code Inspection Checklist

Name Date
Program Program #
Instructor Language Java

Purpose To guide you in conducting an effective code inspection


General - Review the entire program for each checklist category; do not attempt to review
for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the
next.

Part1

Part2

Part3

Part4
Complete Verify that the code covers all of the design.
Initialization - Are there variables or attributes with confusingly similar names?
- Is every variable and attribute correctly typed?
- Is every variable and attribute properly initialized?
- Could any non-local variables be made local?
- Are all for-loop control variables declared in the loop header?
- Are there literal constants that should be named constants?
- Are there variables or attributes that should be constants?
- Are there attributes that should be local variables?
- Do all attributes have appropriate access modifiers (private,
protected, public)?
- Are there static attributes that should be non-static or vice-versa?
-
Method and Class - Is every method parameter value checked before being used?
Definitions - For every method: Does it return the correct value at every method
return point?
- Do all methods have appropriate access modifiers (private,
protected, public)?
- Are there static methods that should be non-static or vice-versa?
- Does each class have appropriate constructors and destructors?
- Do any subclasses have common members that should be in the
superclass?
- Can the class inheritance hierarchy be simplified?

Data Reference - For every array reference: Is each subscript value within the defined
bounds?
- For every object or array reference: Is the value certain to be non-
null?
-
Computations - Are there any computations with mixed data types?
- Is overflow or underflow possible during a computation?
- For each expressions with more than one operator: Are the
assumptions about order of evaluation and precedence correct?
- Are parentheses used to avoid ambiguity?
-
Comparison / - For every boolean test: Is the correct condition checked?
relational - Are the comparison operators correct?
- Has each boolean expression been simplified by driving negations
inward?
- Is each boolean expression correct?
- Are there improper and unnoticed side-effects of a comparison?
- Has an "&" inadvertently been interchanged with a "&&" or a "|"
for a "||"?
-
Control Flow - For each loop: Is the best choice of looping constructs used?
- Will all loops terminate?
- When there are multiple exits from a loop, is each exit necessary
and handled properly?
- Does each switch statement have a default case?
- Are missing switch case break statements correct and marked with a
comment?
- Do named break statements send control to the right place?
- Is the nesting of loops and branches too deep, and is it correct?
- Can any nested if statements be converted into a switch statement?
- Are null bodied control structures correct and marked with braces or
comments?
- Are all exceptions handled appropriately?
- Does every method terminate?
-
Storage - Are arrays large enough?
- Are object and array references set to null once the object or array is
no longer needed?

Modularity - Is there a low level of coupling between modules (methods and


classes)?
- Is there a high level of cohesion within each module (methods or
class)?
- Is there repetitive code that could be replaced by a call to a method
that provides the behavior of the repetitive code?
- Are the Java class libraries used where and when appropriate?
-
Module Interface - Are the number, order, types, and values of parameters in every
method call in agreement with the called method's declaration?
- Do the values in units agree (e.g., inches versus yards)?
- If an object or array is passed, does it get changed, and changed
correctly by the called method?

Input/Output Check the output format.


- Line stepping is proper.
- Spacing is proper.
- Have all files been opened before use?
- Are the attributes of the input object consistent with the use of the
file?
- Have all files been closed after use?
- Are all I/O exceptions handled in a reasonable way?
-

You might also like