Code Analysis – Minimum Rules
This is step 3 in a series of articles, starting with Seven Steps To Quality Code – Introduction.
In this step, things are going to start getting interesting. Up to now, the incremental changes that we have made are fairly non-disruptive – remove some unused variables here, add some XML comments there – not things that are likely to break your existing code (not too much anyway!). This is where we (gently) introduce Code Analysis and start to weed out bugs and refactor the code.
Code Analysis is a feature built in to certain editions of Visual Studio. It will, as its name suggests, analyse your code to detect bad practices, anti-patterns and outright bugs. It does this by validating the code against a predetermined set of rules and reporting violations as warnings in the Error window within Visual Studio.
Originally, this tool used to be available as part of the Windows SDKs (Software Development Kits) from Microsoft. It was called “FxCop” and was a tool that was created to help developers, initially within Microsoft, to build more robust and maintainable code that followed the Microsoft Design Guidelines. If you aren’t lucky enough to be using one of the Visual Studio versions with Code Analysis built-in, then you can download the program in its original “FxCop” guise from here. The interaction with the tool is different, but the underlying system is the same. For the purposes of this article, I’ll be using screenshots and instructions for the built-in Code Analysis.
Now let’s get started. Firstly, to switch on Code Analysis for a solution got to Analyze on the Visual Studio main menu, and select Configure Code Analysis for Solution.
In the dialog that is then displayed, select “All Configurations” in the Configuration dropdown and ensure that the projects on which we want to run Code Analysis are set to “Microsoft Minimum Recommended Rules”, as shown below.
You may see that in the dropdown, there are several “Rulesets” to choose from. These are subsets of the whole set of rules, allowing various levels of compliance to be easily selected. My approach is that we start with the “Microsoft Minimum Recommended Rules” because it contains the most important rules, violations of which are more likely to generate bugs than the rules included in the more complete rulesets.
Next, right click each project in Solution Explorer and Select “Properties” to get the Project Properties screen and then select the Code Analysis tab. Here, you should ensure that “All Configurations” is selected in the Configuration dropdown and check the “Enable Code Analysis on Build” checkbox, as shown below. This will need to be carried out for each project in the solution.
The above step isn’t absolutely necessary, but it means that you or your developers don’t have to remember to run the analysis, Visual Studio will do it for them each time the solution is built. We want to make this whole task integrate completely into the development process and checking this option goes a long way to achieving that.
The next thing to do is simply to build your solution and observe the warnings that are produced.
If you are running this on an existing project, the chances are you will get very many warnings. Don’t be alarmed! A lot of them will be easy to fix and each one fixed means that your code is taking a further step towards the robust and maintainable code that you would like to see.
To help you fix each rule violation, there is excellent documentation available on MSDN. This can easily be accessed by right-clicking a particular warning and selecting “Show Error Help”. This is a fntastic training aid, frequently reading the error help will improve developer knowledge dramatically. This is like having a true .Net guru reviewing the code and providing exact details on how issues should be addressed.
If a rule violation should be allowed in your project for some reason, the warning can be suppressed by right-clicking and selecting “Suppress Messages” then “In Source” or “In Project Suppression File”. This will add an attribute into your code (either at the site of the violation if “In Source” was selected, or in a GlobalSuppressions.cs file if “In Project Suppression File” was selected.
Rules/Guidelines for Using Code Analysis
- Always have the Visual Studio Error window visible. You get immediate feedback on violations following a build (as well as build errors and compiler warnings).
- Fix violations frequently. Fix them as they occur. Don’t leave this as a task to be performed just before check in.
- Always use the error help if the rule isn’t understood
- Follow the error help code suggestions if a fix is not obvious. Some of the IDisposable rule violations spring to mind here as particularly tricky.
- DO NOT SUPPRESS RULES UNLESS IT IS ABSOLUTELY NECESSARY. I cannot stress enough how important this is. Just because a violation looks difficult to correct is certainly not a reason to suppress. In fact, it is probably the case that the more difficult ones to address are the more critical. I recommend that all suppressions are reviewed by a senior member of the team before being authorised. Suppressions are rarely needed, the only suppressions I have allowed recently have been for reasons of backward compatibility.
- If you must suppress, then choose “In Source” rather than “In Project Suppression File”. This means that the suppression is located close to the violation so when the code is modified the violation can be validated. If the whole method is deleted, the suppression will also be deleted. When placed in a project suppression file, the suppressions are all too easily ignored and forgotten about.
Once this is embedded into your development processes, you should really start to see a reduction in defects in the code. The development may initially be slowed as existing code is brought up to the standards required, but once this is achieved, the speed of development should be no slower. The cost of development, however, should be less, because of the fewer defects.
At a client that I have been working with recently, a new piece of software had been released to a customer with 2 call centres employing around 2000 users. Memory leaks in the code meant that the application used more and more memory and resulted in it shutting down twice a day, logging off all the users and restarting. The problem was that nothing was being disposed. Correct implementation and use of IDisposable, as recommended by Code Analysis resolved the issues. If the code had originally been developed with Code Analysis in place, an extremely embarrassing and costly incident would have been avoided.
See you in step 4….