Compiler Warnings, XML Comments, And Code Analysis

In Visual Studio, missing XML comments and code analysis violations generate compiler warnings. In the beginning of a development project, XML comments are typically not written, and code analysis violations may not yet have been taken care of. This causes a large number of compiler warnings to be generated by Visual Studio – often several hundreds.

In at least a couple of cases, I’ve helped other developers troubleshoot bugs in their application where it turned out that the clue and solution to the problem was available as a ‘real’ compiler warning. However, hundreds of XML comment or code analysis warnings had caused the developer to stop looking at compiler warnings at all, so the ‘real’ compiler warning was drowned out by all those other warnings. Even though the solution to the bug was right under the developer’s nose, hours or even days was lost troubleshooting.

This obviously diminishes the value of compiler warnings, which leads some developers to turn off code analysis or XML comments. You can, however, get the best of both worlds:

To avoid the issue of massive amounts of compiler warnings, and to increase compilation speed while I’m developing, I disable both code analysis and XML comments for Debug builds, and enable them for Release builds.

When I’m developing, I do this in the Debug configuration until my code is ready (usually determined by all unit tests passing). Since both code analysis and XML commants are not enabled in my Debug configurations, ‘real’ compiler warnings will show up immediately without being drowned out by all the other warnings. When the code is ready, I change to the Release configuration, where both code analysis and XML comments are enabled, and I polish off the code in that configuration until I have no more warnings.

This simple trick may save you some time, and when code analysis is turned off in the Debug configuration, your code will also compile a lot faster.

Comments (3)

  1. davkean says:

    The problem with this is that issues found by Code Analysis would not be found until too late. I think the better way to deal with the  warnings straight away. Either you are going to fix the issue or not;  suppress the message if not otherwise, fix it straight away.

  2. ploeh says:

    Thank you for your comment. You do raise a valid point that I should have addressed in my post. First of all, your comment relates solely to code analysis, so I assume that you have nothing against my strategy as it relates to XML comments?

    Code analysis warnings should be fixed as soon as possible, I completely agree. However, in reality, many organizations start out coding without, and then switch it on later. While this is not the recommended way to handle code analysis, my approach can help in this scenario.

    On the other hand, this is not the ideal scenario. The correct approach would indeed be to switch on code analysis from the beginning of a project and fix each warning as soon as possible, but even then, my approach lets me focus on the feature I’m currently developing. Before checking in the feature, I polish off the code by looking at my warnings. A by-product of this approach is that while I’m developing, my code compiles a lot faster.

    Most developers are under pressure to deliver features, and at the same time, code analysis can be quite overwhelming if you haven’t used it before. I’ve literally seen code comments like "Make FxCop happy" in user code, which is a fairly good indicator that the developer in question did not understand why he had to fix a warning.

    Although not ideal, my approach allow developers to catch up with code analysis warnings when they have the time to not only fix warnings, but also learn why they are doing so.

    In any case, this method is only a suggestion. If it works for you, then go ahead and use the idea. If it does not, then do whatever else works for you.

  3. Recently, I had turned on Code Analysis for a project of mine and started working through the things…