Code Review Tools and Techniques

Compared to other development activities, code review tends to have less published resources available to help developers stay abreast of the latest review methods, tooling, and best practices.   Arming developers with the knowledge of code review tools and techniques can increase efficiency and reduce the painfulness of the code inspection process.  Making checklists, delegating roles, and implementing reading techniques help developers conduct more focused code reviews, resulting in higher code quality.  Code review and inspection doesn't have to be manual in all areas.  Compiler warnings, static analysis software, and issue/defect tracking can make reviews and inspections more efficient, structured, and semi-automated.  A code review toolset is also a blessing to the reviewer who hates to read code that hasn't been properly prepared.

Preparation, Inspection, Rework, and Follow-up are generally the four stages of code review.  In the Preparation stage, you determine inspection/review targets and the roles for each participant.  Reading techniques should also be specified at this stage.  In the Inspection/Defect Detection stage, each inspector looks for defects according to their assigned role and perspective.  In this stage, compiler warnings, static analysis tools, review tools, and defect tracking tools are put to use.  These tools organize defects for the Rework stage, which is when reviewers go back and fix defects.  Finally there's the Follow-up stage where corrections are verified and reviewers make sure that new bugs haven't been introduced.  Defect tracking and review tools are used here too.  That was a quick run-through.  Now let's look at some of the techniques and tools in detail for each of these stages.

Roles

Reviewer/Inspector:  All members assume this role.  Their goal is to detect and identify defects.
Moderator:  The moderator is responsible for leading the review group and keeping them focused on their goals.  Moderators set up the environment and regulate the discussion to keep reviews focused.  They also manage the time.
Recorder:  This person is responsible for documenting the issues that developers find.  The recorder must summarize the list of defects found.
Author:  The author is a developer who wrote the code being inspected.  It is their responsibility to correct the defects once they are found.
Organizer:  The organizer develops a plan for development and review.  They determine the time schedule for the inspection/review.
Reader/presenter:  The reader explains the product being inspected/reviewed on behalf of the author.

Note that each developer can have more than one role, and each role can have more than one developer.

Reading Techniques

The most common, and probably the best reading technique reviewers can use, is a simple checklist.  These lists contain questions that help developers focus on certain areas in the code.  Questions can be geared towards novice or expert developers and the questions might, for example, ask: "Have resources been properly freed?"  "Will performance suffer from excessively nested loops?"  "Are the data structures used appropriately, taking into consideration trade-offs between performance and memory?"  

Perspective-based reading is another reading technique that assigns a certain point of view to each reader.  Perspectives such as "user" or "tester" will determine how a reader looks at the code and what areas they focus on.  Conducting the review from multiple perspectives is a proven way to have comprehensive code inspections/reviews.  Someone with the user perspective will read the code with use cases in mind while someone assigned to the tester perspective will read through the code thinking about test cases that could prove the code works properly.

Issue Tracking, Static Analysis, and Code Review Tools

Although they're usually not as comprehensive as static analysis tools, most compilers have the ability to issue warnings for statements they think may cause bugs, even though the statements don't cause a compilation error.  Code review tools come with useful productivity features for browsing the source code.  They let reviewers make annotations at any location within the code and then the tool lists those annotations for quick, organized reference.  Issue tracking systems bring another layer of organization to code review by recording and tracking detected defects.  Code review and issue tracking tools are not limited to source-code review alone. They can also be used for the reviewing project plans, requirements definitions, specifications, design documents, test plans, operations manuals, and user manuals..

Jupiter Eclipse plugin for code review


'Source code static analysis tool' is a term that generally refers to a tool that extracts information from the source code without executing the program.  The analysis part includes calculating source-code metrics, using defined patterns to detect potential bugs, and finding instances where coding conventions and rules were broken. Metrics include the number of function or method arguments, the number of function or method calls, the number of branches and loops, and the number of source code lines.  Reviewers benefit from this analysis because it pinpoints areas of the code that are fault-prone.  Static analysis tools also find resource leaks. 

Depending on the sophistication of the static analysis software, there are some tools that will detect areas in source code that are likely to access null pointers or addresses beyond array boundaries.  Certain static analysis tools can also estimate the execution flow of the code.  State-of-the-art static analysis tools are able to identify the location and type of design patterns in the code.  This can help reviewers find potential defects that are common in specific design patterns.

Klockwork's Insight static analysis tool

Conventions

Line breaks, treatment of whitespace (tabs and spaces), and the formatting of conditional statements are conventions associated with readability.  Conventions for extensibility focus on things like using defined constants instead of explicit numbers so you can change the value of a constant to change all instances of that constant throughout the code.  Reliability conventions encourage developers not to use recursive functions or goto statements because they often make the code complex and buggy.  goto statements and recursive function calls may be supported in a language, but it's better if you can find other methods so your code is easier to understand.

Are there any other best practices in your experience with code review?  Suggest some resources.