The Rain and The Shade

March 17, 2012

Visual Studio Add-in for code review

Filed under: C# Coding,Code Quality — ovaisakhter @ 9:16 am


We do use static code analysis on our code and use Resharper as well which I am not sure where to place category wise but surely it is the best tool next to visual studio a developer can have. Although these tools have made the life of  the Architects lot easier,  a manual code reviews (if I may say it so) are still very relevant.

Some while back I had to do a code review for a decent sized project.  For some one as Lazy as I am it is a struggle to write down the review reports. It is a pain to write down the context information like project, file, line number and then some selected text to for each defect report. I  Googled for a  tool which can make my life easier, but most of the tools I found were a bit to complex for my need and on top of that most of them were coupled with some particular source control (not to mention they were not free also).

The Add-In

Eventually I thought of writing a very simple version myself. Here are the requirements for this simplest version

  • should be able to show it in visual studio
  • should be able to write a description of the issue
  • should get the context following context information
    • Solution Name
    • Project Name
    • File Name
    • Line Number
    • Selected Text
  • should be able to append these reports to a text file

In this post I will try to introduce you the addin and its capabilities which are not many and how to install it. I will explain a bit more about the code in my next post. I will how ever put a link to the source code in the end if you want to look at it.

Once you install the plug in you get a menu item in your tools menu “Code Review” once this item is clicked a visual studio tool window is loaded with the code review form. You can dock this window in visual studio for easy access. Here is how it looks like after docking.


So the plug in offers you some very basic capabilities. Once loaded you can select a text file where all of your review will be saved. You can go to a file and may be select some text and on the window start writing an issue description and puff the above mentioned context information appears in the context box. once done with the description  you can click the append to file button and the description along with the context information will be saved in the text file.



and when you click append to file here is what is saved to the file

Code Review Defect Report
this code generated by visual studio really stinks, well not really I am just doing to create a fake code defect report
Solution: C:\Users\Ovais\documents\visual studio 2010\Projects\Wisdom.VisualStudio.Tools\Wisdom.VisualStudio.Tools.sln
Project: Wisdom.VisualStudio.TestApplication
File: Program.cs
Line: 19

Selected Text: Application.EnableVisualStyles();
Application.Run(new Form1());



I have not made any fancy installation setup with this so you will have to do the following steps manually

  1. Copy the contents of the to a folder on your computer e.g. c:\Wisdomplugins
  2. in the visual studio go to tools menu and then select options
  3. in the options dialog select Environment/Add-in/Macros Security
  4. Click the add button and provide the path of your newly created folder.
  5. restart the visual studio and with a stroke of luck you will see the menu item in the tools menu

I have only tested this on the English version and I am pretty sure it will not work on any other language Smile.

You can get the code for the Add-in from the following location.

As I mentioned I will explain the code of the Add-in in a later post. So if you are interested stay tuned.

Happy reviewing!


November 7, 2011

The Broken Window (Maintaining coding best practices in organizations)

Filed under: Code Quality,General Software Archiecture,Project Management — ovaisakhter @ 1:47 pm

Recently I attended a seminar by Roy Osherove about good practices in unit tests. Although all the seminar was full of information and useful ideas. I particularly liked the concept called Broken Window Theory. Idea is that if a diversion from the normality or pattern is made at one place, it will be replicated to all multiple places in the code. Other developer looking at the code will feel that it is fine to do something like this.

The question is how to avoid the broken windows in the code of a team or a software development company where a lot of people are developing code and there are very few to review it.

I am a big supporter of code analysis tools, and have been advocating them in my organization. We have been using FXCop and lately we having been using ReSharper.

For FxCop I like to have a basic set of rules that should be followed by all the projects. What we try to achieve with this is that all the code going out of the development shop has certain basic standard. Once a new project starts the architect looks into the standard rules and see what additional rules should be added to the rule set for this project. A combination of these rules then becomes the standard rule set for that project.

Standard operating procedure for developers is not to check-in before all the errors and warnings have been removed. FxCop helps a lot achieving this goal with the annoying warnings. We cannot use check-in policies as we use multiple source control tools. “Treat Warnings as Errors” is always on in the project properties. The code analysis is also done on the build servers after every check-in. In case of Resharper we use the out of the box refactoring scheme, the SOP is to follow all the suggestions.

All the static code analysis tools provide the facility to exclude a portion of the code from being being evaluated for a particular rule. And some times it is justifiable to exclude a certain rule. This is very convenient for the developers to do that even if there is not enough justification. The question here becomes on how to avoid the broken window effect when we make such exclusions.

In this case we like to follow the practice that I like to call “Justify and publish”. As a developer you are allowed to deviate from a rule if and only if you

  • 1) Writes a comment with the code with a reason of deviation.
  • 2) Publish this deviation to the project development wiki

this way the developers do not go on sabotaging the patterns at will. If some one else sees the diversion he can see that this was deliberate and for some reason and he will not replicate this every where. Publishing the information on the development wiki architects and other developers get a chance to wet the diversion and may suggest a better approach to solve the issue. Yet there is no time wasted for the developer.

Blog at