The Code Analysis feature in Visual Studio 2010 Sucks
I’m leading the switch from Visual Studio 2008 to Visual Studio 2010 at my company. In addition to the usual migrating of countless projects and fixing niggling errors, I’ve thought it would be cool to use the Code Analysis feature built in to VS 2k10 to automatically run our new C# code through a set of rigorous checks for bad code smells and possible bugs. From a policy perspective it was really easy; I made a new ruleset comprised of most of the MSFT rules which ship with the product, then configured the C# projects to perform code analysis with my custom ruleset file. Then the FAIL started.
First, I wanted Code Analysis warnings to be included in the ‘Treat Warnings as Errors’ feature of the compiler. That’s not possible, so instead I had to change every warning in my ruleset into an error. Nice.
Next, I wanted to get existing code under analysis even though it generates tons of warnings, by excluding all existing files in my legacy projects. This way, as files are added they will be checked, but existing files don’t have to be fixed all at once. Turns out, you can’t do that. The rules are the rules, for every file in the project.
After that, I brought a simple NUnit test suite project into the Code Analysis fold. The project was dead simple, so I didn’t expect any Code Analysis violations. Little did I know. You see, most (actually, all) of my unit tests are public non-static methods which do not access any instance methods or variables. Code Analysis issues warning CA1822, pointing out that the method could be made static for better performance. Normally this is 100% correct and I want to be alerted to it, but these are unit tests. They MUST NOT be static. Thus, I decided as a matter of policy that CA1822 would be ignored for unit test projects.
Only, that’s not how it works. The SuppressMessage attribute suppresses ONE instance of a warning. If you have a code file with 100 warnings, there’s no way to suppress all warnings in that file. None whatsoever! I can only imagine the conversation between preening code bureaucrats at MSFT:
“We should probably have a way to disable some of these warnings on a file or space basis”
“Why? Then stupid users will just disable the warnings instead of addressing them. Let’s make them create a separate SuppressMessage attribute for every single violation. It’ll make their code look like shit, and will piss them off so much they just quit using Code Analysis entirely”
“Prescriptive, simplistic, crude, and ultimately useless. I like it!”
As a result, we have a feature that should’ve been integrated into Visual Studio long ago, implemented in such a way as to be useless to most real world software projects.