Best practices for code review sessions with Visual Studio Team System

If you are working in a software development team and you are sitting periodically together to review the code that has been written, it is important to know what to do, but also how to do it properly. Generally speaking, there are several best practices that are universal to almost any more or less formal meeting, be it a code review session or not. In addition to these common rules, there are several rules that apply to code reviews.

On MSDN, there's a nice topic called "Guidelines for Conducting Design and Code Reviews", which lists the following. Lets start with two I'd categorize as common sense:

• Prepare for the meeting. That is, review the code yourself before going to the meeting, and do not attempt to do so during the meeting. This will save the time of all other attendants.
• Follow a predefined list to topics/tasks to check during the meeting. Otherwise, the discussion might flow into wrong directions, or you might find that you will forget to review certain aspects of the code.

Then, specific to code review sessions:

• Don't rush the schedule. It is of course necessary to allocate some time to the meeting, but if there are more issues found than time would allow, either continue the meeting, or schedule a second one close by. If you skip items on the list because of time constraints, you will sacrifice code quality.
• Track the issues found during code reviews. This tracking could be Visual Studio Team System work items, TODO comments in the C# source code, or similar. Personally, I'd use work items for "larger" changes that need to be made, and code comments for "smaller" changes. Of course, what is large or small depends on your project.
• Don't change the code while it's in review. If you find problems in your code while you've "checked out" the code to your reviewers, they will not be able to review what you've written.

By following these simple rules you can improve the quality of your software development process, and in the end the quality of the .NET applications you build. And that's what we're all after, right?