Painless Software Development Part 4

4th July 2010

Please read the following first:

In the final part of the series on Painless Software Development, I continue with the possible techniques that will help us to detect bugs early into the development before the code is committed to the main repository.

3) Assertions
One of the tools that we can use during the implementation to easily detect bugs caused by improper input arguments to the functions is the assert macro. Assert can be found in assert.h. The way to use assert is:

#include "assert.h"
void func(char* pString)
{
   assert (pString != NULL);
}

In this case, if pString turns out to be NULL when we pass it into the function func, in most compilers, assert will cause the debugger to stop at that particular point where the assertion has been placed indicating that the condition turned out to be false. Assert macro expands into code only in the debug version and in the release version it is replaced by nothing. So it helps in detecting potential bugs in the debug version while remaining completely invisible in the release version virtually placing no additional burden on the release version.

Assert macros should be used only for checking the entry points of functions and should not replaced error checking in the source code. Also care must be taken to ensure that adding assertions does not alter the execution of the software in any way i.e they should not alter the state of the variables, memory, files, etc so that the debug version and the release version of the software produce the same results.

4) Debugging
Bugs are introduced into the system either by writing new code or by modifications to the existing code. So whenever new code has been added or modifications have been made to the existing system, stepping through each of the new line of code while checking that it performs it’s intended purpose is a good way to ensure that are not adding logical bugs into the system.

Once the code is running and producing results that we expect, we tend to relax with a feeling that since the code is working there might not be bugs in it. However, there can be several issues that we do not consider such as a particular execution path is not being reached. Or that some of the variables may contain improper values perhaps even be working with garbage values. Debugging through your source code while checking the state of the variables and the path of execution will help to detect such kinds of situations which may turn into major bugs later in the development process.

A useful functionality of the debugger is the ability to change the values of variables during the execution. By altering the values of the variables we can check the different execution paths of the program thus increasing the coverage of our code and uncovering potential problems.

By stepping through your code, you could find the following types of bugs:

Overflow and underflow bugs
Data conversion bugs
Off-by-one bugs
NULL pointer bugs
Bugs using garbage memory
Assignment bugs in which you’ve used = instead of ==
Precedence bugs
Logic bugs

5) Code Reviews
Once the developer has implemented and tested the functionality of the source code and feels that it is complete, before finalizing the source code, it must be ensured that a thorough code review is performed for the new or modified code. The implementation should be explained to another developer with scope such as what was the requirement, how was it implemented, why a particular design was chosen, etc.

The reviewer on his part should examine the source code for possible discrepancies based on his experience. Viewing the source code with a different pair of eyes can can help recognize potential bugs that might not be recognized by the developer. A set of code review guidelines can be created to ensure that the quality of the source code remains unaffected by the new implementation or modifications to the source code.

Painless Software Development Part 4

Related Posts:

Recent Posts