39. Software Development Practices – Code Reviews
Was sufficient “white box” testing performed to assure that internal logic, control features, and data processing work as specified? (p. 90)
IEEE defines “White Box” testing as testing based on an analysis of the internal structure of the component or system. Software code reviews are a prime example of white box testing.
Code reviews are a software engineering practice whereby a developer’s code is examined by one or more peer professionals to assess the code’s ability to perform its expected task and its compliance to the project’s architectural standards and related functional and design specifications. The code review level is the most cost effective place to find and correct errors in software development. Unfortunately many teams try to do as few code reviews as possible because they see them as onerous time delays and a drag on the reviewer’s productivity since he/she can’t be doing their own programming when they are reviewing someone else’s code. In reality, identifying and fixing bugs later on in the life cycle incurs geometrically increased product costs.
Some teams address code reviews with a buddy system for paired programming in a specific functional or design area of the product. Both programmers work as a complementary team to produce the software code and trade off to review each other’s code and then unit test it before adding it to the common build of the software product. Excerpts from a code review checklist published by Canadian company Macadamian is summarized in the table below.
|Excerpt of Macadamian’s Code Review Checklist
|General Code Smoke Test||Does code build correctly & execute as expected?
Do you understand the code you are reviewing?
Has developer unit tested the code before sending it for review?
|Comments & Coding Conventions||Does code respect the project coding conventions?
Does the source file start with an appropriate header information?
|Error Handling||Are errors properly handled each time a function returns?
Are resources and memory released in all error paths?
|Resource Leaks||Is allocated memory (non-garbage collected) freed?
Are all objects (Database connections, Sockets, Files, etc.) freed even when an error occurs?
|Thread Safeness||Are all global variables thread-safe?
Are locks released in the same order they are obtained?
|Control Structures||Are loop ending conditions accurate?
Is the code free of unintended infinite loops?
For a copy of the complete checklist send a request to email@example.com.
Next Month: Software Development Practices – Smoke Test
Smoke Test: Project regression test to ensure a safe Software Quality Control (SCQ) Build. (p. 90)