SKU: Premium, Ultimate
Versions: 2008, 2010
In my extensive travels with my good friend Clint Edmonson (http://www.notsotrivial.net/blog/) we found yet another feature available in Visual that seems to be underutilized: Static Code Analysis. After some digging, we discovered many people don’t realize they have this feature already and can use it anytime they want to warn of possible issues. I thought it would be instructive to start with a basic understanding of code analysis and, in a series of tips, dig into the specific implementation.
Let’s begin with a basic definition from Wikipedia on static code/program analysis:
“Static program analysis is the analysis of computer software that is performed without actually executing programs built from that software (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code. The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding, program comprehension or code review.”
Essentially, we have a set of rules that we use to examine our code and see if there are any issues that arise. Static code analysis is a great way to avoid common pitfalls in your code. Not only can you use a set of predefined rule sets but you can make your own rule sets from existing rules and even create custom rules specific to your needs.
Given the complexity of this topic the best way to learn is by doing. So let’s go through a simple example using code analysis. First, create a new C# class library project (give it any name you want) and then create a method as I have done here:
By default, projects are set to use the Microsoft Minimum Recommended Rules set which essentially does what is says and ensures the bare minimum set of rules are applied when used. I’ll get into the details of what those rules are in later tips but, for now, let’s see if there are any issues that crop up with this small set of rules. Right-click your project in Solution Explorer and choose Run Code Analysis:
Problems will show up in your Error List window as errors or warnings. Notice we have neither in this case which shows that there aren’t any violations with the minimal rule set. Now let’s go to the other extreme and apply the strictest rule set possible. Go into your project properties and click the Code Analysis tab:
Notice the Rule Set area? Click the drop-down list under Run This Rule Set to see the list of rules that are available and select Microsoft All Rules from the list:
Note the description for this rule set:
This will produce the largest amount of noise in your Error List window so be warned. I only suggest using this rule set as a way to find out what rules apply to certain areas of your code. To my knowledge only internal Microsoft developers are regularly required to use this level of strictness.
Now that you are using this new rule set, right-click your project in Solution Explorer and run code analysis again. Notice we now get some warnings that we can address:
You are welcome to explore these warnings on your own to get more detail. Just click any warning and press F1 to get help on it. Right now I am just interested in the last one in the list called CA1801. It’s definitely telling us we need to either use the parameter for the method or remove it. We could correct the issue:
Then rerun code analysis to make sure it passes the check:
At this point you have just enough information to scratch the surface of code analysis. We will continue to dig deeper into this amazing feature over the next few tips.