Thursday, September 09, 2010

Warnings and Code Analysis

During development, I do my best to ensure that I eliminate warning and issues identified through code analysis. I like to do this from the start so I don’t have a massive list of “clean up” at the end of a project.

Unfortunately not all of the projects I work on start from a clean state. Like me, many developers inherit a large code base that needs to be extended, patched and enhanced. More often then not, these projects come with hundreds or even thousands of compiler warnings and have probably never been run through any static code analysis.

For code analysis, I have used FxCop and now Visual Studio Code Analysis. Using these tools, I can identify issues and correct them. On a few occasions however, the “issues” are by design and I can easily put a suppression on the error. Suppressions can happen at many levels, but I prefer to generally suppress issues at the lowest possible level. This makes me review every instance of an issue instead of blindly hiding things.

When you suppress a code analysis warning, you can add in an options reason for the suppression. This acts as inline documentation that allows me to share my reasons for doing this.

Now, this is where I currently have an issue. Compiler warnings don’t allow suppressions on a per-instance level. The best we have is the ability to suppress all warning of a type for a particular project.

I’d like the ability to attribute methods, properties or classes to suppress compiler warnings just like I can with my code analysis. Not only that, I’d like to be able to leave documentation as to why I’ve suppressed a compiler warning.

I guess what I’m asking for is to just implement support for compiler warnings that’s identical to code analysis in Visual Studio. This would make my life a lot easier, particularly when working with large inherited code bases.

No comments: