CODE REVIEW

Read Time:7 Minute, 31 Second

Testing is an effective defect removal mechanism.

However, testing is applicable to only executable code.

Review is a very effective technique to remove defects from source code. In fact, review has been acknowledged to be more cost-effective in removing defects as compared to testing.

Code review for a module is undertaken after the module successfully compiles.

That is, all the syntax errors have been eliminated from the module. Obviously, code review does not target to design syntax errors in a program, but is designed to detect logical, algorithmic, and programming errors.

Code review has been recognised as an extremely cost-effective strategy for eliminating coding errors and for producing high quality code.

The reason behind why code review is a much more cost-effective strategy to eliminate errors from code compared to testing is that reviews directly detect errors.

On the other hand, testing only helps detect failures and significant effort is needed to locate the error during debugging.

The rationale behind the above statement is explained as follows.

Eliminating an error from code involves three main activities
testing
debugging,then correcting the errors.

Testing is carried out to detect if the system fails to work satisfactorily for certain types of inputs and under certain circumstances.

Once a failure is detected, debugging is carried out to locate the error that is causing the failure and to remove it.

Of the three testing activities, debugging is possibly the most laborious and time consuming activity.

In code inspection, errors are directly detected, thereby saving the significant effort that would have been required to locate the error.

Types of reviews

Normally, the following two types of reviews are carried out on the code of a module:

Code inspection.

Code walkthrough. The procedures for conduction and the final objectives of these two review techniques are very different.

Code Walkthrough

Code walkthrough is an informal code analysis technique. In this technique, a module is taken up for review after the module has been coded, successfully compiled, and all syntax errors have been eliminated.

A few members of the development team are given the code a couple of days before the walkthrough meeting.

Each member selects some test cases and simulates execution of the code by hand (i.e., traces the execution through different statements and functions of the code).

The main objective of code walkthrough is to discover the algorithmic and logical errors in the code.

The members note down their findings of their walkthrough and discuss those in a walkthrough meeting where the coder of the module is present.

Even though code walkthrough is an informal analysis technique, several guidelines have evolved over the years for making this naive but useful analysis technique more effective.

These guidelines are based on personal experience, common sense, several other subjective factors.

Therefore, these guidelines should be considered as examples rather than as accepted rules to be applied dogmatically.

Some of these guidelines are following:

The team performing code walkthrough should not be either too big or too small.

Ideally, it should consist of between three to seven members. Discussions should focus on discovery of errors and avoid deliberations on how to fix the discovered errors.

In order to foster cooperation and to avoid the feeling among the engineers that they are being watched and evaluated in the code walkthrough meetings, managers should not attend the walkthrough meetings.

Code Inspection

During code inspection, the code is examined for the presence of some common programming errors.

This is in contrast to the hand simulation of code execution carried out during code walkthroughs.

The principal aim of code inspection is to check for the presence of some common types of errors that usually creep into code due to programmer mistakes and oversights and to check whether coding standards have been adhered to.

The inspection process has several beneficial side effects, other than finding errors.

The programmer usually receives feedback on programming style, choice of algorithm, and programming techniques.

The other participants gain by being exposed to another programmer’s errors.

As an example of the type of errors detected during code inspection, consider the classic error of writing a procedure that modifies a formal parameter and then calls it with a constant actual parameter.

It is more likely that such an error can be discovered by specifically looking for this kinds of mistakes in the code, rather than by simply hand simulating execution of the code.

In addition to the commonly made errors, adherence to coding standards is also checked during code inspection.

Good software development companies collect statistics regarding different types of errors that are commonly committed by their engineers and identify the types of errors most frequently committed.

Such a list of commonly committed errors can be used as a checklist during code inspection to look out for possible errors.

Following is a list of some classical programming errors which can be checked during code inspection:

Use of uninitialised variables.

Jumps into loops.

Non-terminating loops.

Incompatible assignments.

Array indices out of bounds. Improper storage allocation and deallocation.

Mismatch between actual and formal parameters in procedure calls.

Use of incorrect logical operators or incorrect precedence among operators.

Improper modification of loop variables.

Comparison of equality of floating point values.

Dangling reference caused when the referenced memory has not been allocated.

Clean Room Testing

Clean room testing was pioneered at IBM.

This type of testing relies heavily on walkthroughs, inspection, and formal verification.

The programmers are not allowed to test any of their code by executing the code other than doing some syntax testing using a compiler.

It is interesting to note that the term cleanroom was first coined at IBM by drawing analogy to the semiconductor fabrication units where defects are avoided by manufacturing in an ultra-clean atmosphere.

This technique reportedly produces documentation and code that is more reliable and maintainable than other development methods relying heavily on code execution-based testing.

The main problem with this approach is that testing effort is increased as walkthroughs, inspection, and verification are time consuming for detecting all simple errors.

Also testing- based error detection is efficient for detecting certain errors that escape manual inspection.

SOFTWARE DOCUMENTATION When a software is developed, in addition to the executable files and the source code, several kinds of documents are developed as part of the software engineering process such as

users’ manual

software requirements specification (SRS) document

design document

test document

installation manual, etc.

All these documents are considered a vital part of any good software development practice.

Good documents are helpful in the following ways:

Good documents help enhance understandability of code. As a result, the availability of good documents help to reduce the effort and time required for maintenance.

Documents help the users to understand and effectively use the system.
Good documents help to effectively tackle the manpower turnover problem. Even when an engineer leaves the organisation, and a new engineer comes in, he can build up the required knowledge easily by referring to the documents.
Production of good documents helps the manager to effectively track the progress of the project. The project manager would know that some measurable progress has been achieved, if the results of some pieces of work has been documented and the same has been reviewed.

Types of Software documents

Software documents can broadly be classified into the following:

Internal documentation: These are provided in the source code itself.

External documentation: These are the supporting documents such as SRS document, installation document, user manual, design document, and test document.

Internal Documentation

Internal documentation is the code comprehension features provided in the source code itself.

Internal documentation can be provided in the code in several forms.

The important types of internal documentation are the following:

Comments embedded in the source code.

Use of meaningful variable names. Module and function headers.

Code indentation.

Code structuring (i.e., code decomposed into modules and functions).

Use of enumerated types. Use of constant identifiers.

Use of user-defined data types.

Careful experiments suggest that out of all types of internal documentation, meaningful variable names is most useful while trying to understand a piece of code.

External Documentation

External documentation is provided through various types of supporting documents such as users’ manual, software requirements specification document, design document, test document, etc.

A systematic software development style ensures that all these documents are of good quality and are produced in an orderly fashion.

An important feature that is required of any good external documentation is consistency with the code.

If the different documents are not consistent, a lot of confusion is created for somebody trying to understand the software.

In other words, all the documents developed for a product should be up-to-date and every change made to the code should be reflected in the relevant external documents.

Even if only a few documents are not up-to-date, they create inconsistency and lead to confusion.

Another important feature required for external documents is proper understandability by the category of users for whom the document is designed.