Rules for warnings and my biased view of the ObsoleteAttribute

Brad has a hot post going about how we should handle the ObsoleteAttribute and its usage in the Framework. Brad’s post is balanced and objective to not force people into one camp or another. Let me be totally biased, put my Development Manager hat back on for a minute, and articulate my rules for handling warnings in a software project:

 

  1. A compiler must never issue a warning that is not meant to describe dangerous behavior. Warnings need to point to dangerous coding errors, that while you might be getting lucky right now, they most likely are a bug waiting to happen (say when you move to 64-bit or a chip with a different endian ordering).
  2. Your project should compile with warnings as errors (eg: /wx). Warnings point to sloppy code that must be fixed. Period. Having “known” warnings in a project is a dangerous thing and hides new ones that show up.
  3. #pragma’s should not be used to disable warnings. Hiding warnings is another way of letting sloppy code make its way through. If a compiler strictly sticks to rule #1, it should never be necessary. If you find bogus warnings that don’t meet rule #1, report them. They are bugs.

 

Let me circle back to Brad’s post. The reason I do not like the way ObsoleteAttribute is handled in the Framework is it doesn’t strictly follow these rules. If the attribute is used to describe a method/type which we have decided to obsolete for security reasons, you should definitely get off the type immediately. Get in my face. But giving me suggestions for new types that have new features and other improvements is not dangerous behavior. It’s a suggestion. My code will continue to work just fine and without error. If you have ever worked on a project with millions of lines of code and hundreds (thousands?) of assemblies, you know that churning code just because is not always a good thing to do. The changes can become invasive if you have to pass around new types and break your inter-assembly contracts.

 

I do like the idea of having prescriptive guidance when you are introducing new and improved ways to do things. For example, nothing is harder than sitting in front of MSDN looking at two versions of the same thing (honestly, how many ways do we really need to read XML?) and not knowing what to do. Attributing types with suggestions on the best thing to do makes sense. Intellisense and doc files can favor the winners without violating my rules.