Code Review Tools and Techniques
Join the DZone community and get the full member experience.Join For Free
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.
RolesReviewer/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 TechniquesThe 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
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
ConventionsLine 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.
Opinions expressed by DZone contributors are their own.