A code review is similar to a design review except that it analyzes the code instead of the design. To perform a code review, give one or more developers printouts of the VIs to review. You also can perform the review online because VIs are easier to read and navigate online. Talk through the design and compare the description to the actual implementation. Consider many of the same issues included in a design review. During a code review, ask and answer some of the following questions:
What happens if a specific VI or function returns an error? Are errors dealt with and/or reported correctly?
Are there any race conditions? A race condition occurs when two or more pieces of code that execute in parallel change the value of the same shared resource. Because the outcome of the VI depends on which action executes on the shared resource first, race conditions cause unpredictable outcomes. Race conditions often occur with the use of local and global variables or an external file, although race conditions can exist any time more than one action updates the value of the same stored data.
Is the block diagram implemented well? Are the algorithms efficient in terms of speed and/or memory usage?
Is the block diagram easy to maintain? Does the developer make good use of hierarchy, or is he placing too much functionality in a single VI? Does the developer adhere to established guidelines?
There are a number of other features you can look for in a code review. Take notes on the problems you encounter and add them to a list you can use as a guideline for other walk-throughs.
Focus on technical issues when doing a code review. Remember to review only the code, not the developer who produced it. Do not focus only on the negative; be sure to raise positive points as well. Several third-party resources contain more information about walk-through techniques.