what are code inspections/inspection codes - csmates.com

code inspections/inspection codes

Code Inspection technique is well known and is a silver bullet that can drastically improve the code while reducing delivered bugs. Code inspections are one of the most powerful tools for eliminating bugs.
code inspection in software engineering

Formal code inspections are probably the most important tools you can use to get your code out faster with bugs. The inspection plays on the well-known fact that "two heads are better than one."

The goal of code inspections is to identify and remove bugs before testing the code.

The best code inspections come about from properly organized teams. Experience indicates that when management is involved usually only the most superficial bugs are caught since no one wishes to show the author to be the cause of major program defects.  

Four formal roles exist the Moderator, Reader, Recorder, and Author.

  • The Moderator,  who must be very competent technically, leads the inspection process. He/she paces the meeting, coaches other team members, deals with scheduling a meeting place and disseminating materials before the meeting, and follows up on rework.
  • The Reader takes the team through the code by paraphrasing its operation. Never let the Author take this role, since he may read what he meant instead of what he implemented.
  • A Recorder notes each error on a standard form. This frees the other team members to focus on thinking deeply about the code.
  • The Author's role is to understand the errors found and to illuminate unclear areas. As code inspections are never confrontational, the author should never be in a position of defending the code.
Code inspections are a process consisting of following several steps that are required for optimal results.

  • When the source code complied cleanly with no error or warning messages, the author submits the listing to the Moderator, who forms an inspection team.
  • The moderator distributes listings to each team member,  as well as other related documents such as design requirements and documentation.
  • The moderator does the bulk of the planning process.
  • An effective moderator respects the time constraints of his colleagues and avoids interrupting them.
  • This optional step is a meeting for cases where the inspection team members are not familiar with the development project.
  • The author provides enough background to team members to facilitates their understanding of the code.
  • Inspectors individually examine the code and related materials.
  • They use a checklist to ensure they check all potential problem areas.
  • Each inspector marks up his/her copy of the code listing with suspected problem areas.
Inspection Meeting
The entire team meets to review the code.
The moderator runs the meeting tightly.
The only subject for discussion is the code under review.

The person designated as the reader presents the code by paraphrasing the meaning of small sections of code ina context higher than that of the code itself.

All errors are recorded and classified as major or minor. A major bug is one that if not removed could result in a problem that the customer will see. Minor bugs are those that include spelling errors, non-compliance with the firmware standards, and poor workmanship that doesn't lead to a major error.

  • The author makes all suggested corrections, gets a clean compile, and sends it back to the moderators.
  • The moderator checks the reworked code. If the moderator is satisfied the inspection is formally complete and the code may be tested.
Checklist for Code Inspections
Here are 8 checklists for code inspections.

1.Data Declaration
  • All variables defined?
  • Correct lengths, types, and storage classes assigned.
  • Initialization consistent with storage class?
  • Arrays and strings initialized properly?
  • Any variables with similar names?
Data Reference
  • Subscript within bounds?
  • Record and structure attribute match?
  • Off-by-one errors in indexing or subscription operations?
  • Correct attributes when aliasing?
  • String limits exceeded?
  • Mixed-mode computation
  • Computation on non-arithmetic variables.
  • Computations on variables of different lengths?
  • Intermediate result overflow or underflow?
  • Division by zero?
  • Target size less than the size of assigned values?
  • Variable's value outside the meaningful range.
  • Comparison between inconsistent variables?
  • Comparison relationship correct?
  • Boolean expressions correct?
  • Operator precedence understood?
Control Flow
  • Multi-way branches exceeded?
  • Will each loop terminate?
  • Will the program terminate?
  • Any loop bypasses because of entry conditions?
  • Off-by-one iteration errors?

  • File attributes correct?
  • Open statements correct?
  • Format specifications match I/O statement?
  • Buffer size matches record size?
  • End-off-file conditions handled?

  • A number of input parameters match the argument list?
  • Types of input parameters match the argument variables?
  • Global variable definitions consistent across modules?
  • Constants passed as arguments?

Other Checks
  • Missing functions?
  • Input checked for validity?
  • Any unreferenced variables in cross-reference listing?
  • Are compound conditions specified properly?
Benefits of Code Inspections
Some of the benefits of code inspections
Indicates all the defects that otherwise are difficult to find during normal operational testing and usage.
Lists all potential design flaws that can make software code less maintainable and costly to develop.
It generates source code documentation that can make it easier for people to add new code and maintain existing code.

Post a comment