Introduction
As a developer, I look for tools that help me get things done quicker, and make tasks easier. This series of articles shows you how to take a handful of the features in SlickEdit Tools and use them to effectively put together and perform a code review.
I can't say that I've met too many developers that eagerly looked forward to reviewing code. Most developers understand the importance of code reviews, but many have experienced the pain of poorly run code reviews. Although SlickEdit Tools does not have a "code review" feature, it provides several features that can be used together to make a code review run smoothly. A well done code review process can be the difference between developer loathing and developer buy-in.
Because code reviews are such a big topic, this article will focus on some of the steps that lead up to a code review. Code reviews typically focus on the work of a single developer, so we'll start there. We are going to be code reviewing the developer with ID SLICKEDIT\shackett (or Scott) in source control, and we'll be reviewing his work since March 3, 2008, which is the date of our last (fictional) release.
Finding the Best Files to Review
Our first challenge involves finding the set of files that Scott has worked on since March 3, 2008. We'll use the Find Version feature of the SlickEdit Tools Versioning Toolbox as our starting point.
Find Version allows you to query versions of the source code files in your solution. The code review organizer can use this feature to find an ideal set of files to review. Simply click SlickEdit > Find Version to bring up the Find Version tool window. For this example, we'll find versions with the following criteria:
- Since date: Finds all versions checked in since a particular date, such as the last release.
- Developer name: Finds all versions checked in by one or more specific developers.
These two criteria are used to find all versions checked in by Scott during the latest development cycle (March 3, 2008 - present).
No development team has the resources to code review every file in that list, so it's important to find the best candidate files to review. Therefore the next task is to look through the results and find a sampling of files that represent the most important or complex code. You might also include some files that have a high number of check-ins by that developer, which indicates high rate of change, or churn. These are the ideal candidate files to be reviewed. Email the names of those files to all developers who will be participating in the code review.
In this example, PackageBaseWhidbey.cs has had several changes and is a very important file, so we'll include that in our code review process.
Loading the Files to Review
When a developer is ready to prepare their review comments, they should close all other files and open the files in the list sent by the code review organizer. This can be done quickly using the Load Files feature in the Editing Toolbox, which allows you to quickly filter the list of files in your solution and open the ones you're looking for. Click SlickEdit > Load Files to use this feature.
By typing basew in the filter, we narrow down the files in the list to only those that include that text in their file name. We'll select PackageBaseWhidbey.cs and open it.
Isolating a Developer's Work
One of the most difficult things to do when reviewing the code of another developer is actually identifying the work that that developer did, especially if it was done as part of a team. Once you have PackageBaseWhidbey.cs open, we'll use the Version Visualizer feature of the Versioning Toolbox to see which parts Scott has worked on. Click SlickEdit > Version Visualizer to show this tool window. Next, select Default User Scheme in the drop down at the top of that tool window.
The versions of the file will be processed and the tool window will list the names of all developers who have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify who wrote each line of the file.
You can find Scott's name (SLICKEDIT\shackett) in the tool window list and double click on it to go to the first line of code he contributed. You can then use the next and previous button on the tool window to navigate through the blocks of his work.
To make Scott's work stand out more distinctly, select his name (SLICKEDIT\shackett) in the list and click the Toggle Selection Visibility toolbar button. When toggled on, Scott's work will stand out, and all other developer's work will be dimmed out. This allows you to quickly see what code is Scott's and what code isn't. You can click this button again to toggle it back off.
Another option is to assign a unique color to Scott. To do this, click the Configure Visualization Schemes button on the Version Visualizer toolbar. This will bring up the Scheme Builder dialog. We'll create a new scheme to highlight all areas of code worked on by Scott. Click the Add new scheme button and give the scheme a name of Scott's code. We can now add a scheme item for Scott and give it a color of bright red.
We can save this visualization scheme and then apply it by selecting it in the Version Visualizer drop down. This same scheme can be applied to any file to highlight areas of the code written by Scott.
If you find a block of code written by the developer being reviewed that looks questionable, you may want more context about the developer's intent, such as the check-in comment made when that section of code was checked in. This information is very important for creating meaningful code review comments. The easiest way to do this is to see which version that code was checked in as, and look at the comment associated with that version. To do this, select Default Relative Age Scheme in the drop down at the top of the Version Visualizer tool window.
Again, the versions of the file will be processed, but now the tool window will list the IDs of all versions that have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify which version last updated each line of the file. The colorizing of each segment corresponds to the age of the version it was checked in with (dark is oldest; light is most recent).
You can find the version associated with the questionable code and take a look at the comments associated with it. You can also use the Next and Previous button as before to see all of the code in the file that was updated as a result of that check-in. For instance, we may have disagreed with the AddMenuCommandHandler function being public. We can see that change was part of version 762. By hovering over that version in the Version Visualizer tool window, we get a better understanding of why the function was made public. All of these features assist the team in making judgments about which code to review. They also provide some insight into the motivation the developer being reviewed might have had when checking a set of code in.
Next is the task of actually commenting on the code. This task is always best done in electronic format, in a way that can be pulled together as part of the code review meeting. The next article in this series will go through some of the features of SlickEdit Tools that facilitate writing comments about code and tying them directly to the source, without modifying the files.
Take it For a Spin
At SlickEdit, we are confident that you will be as excited about the latest release of SlickEdit® Tools 2.0 for Microsoft Visual Studio as we are. Download the trial version and try it out for yourself.
