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.

Comments (10)

  1. Eric Newton says:

    Just playing devil’s advocate:

    Are those rules your rules, or some standard set? If yours, then obviously the ObsoleteAttribute doesnt handle your view.

    Warnings are dangerous? maybe you have a good point here, even though being warned that "variable A is never assigned a value and will always have null." is a good warning… probably not dangerous, but still a good warning…

  2. David Levine says:

    I always compile with warnings as errors – I don’t tolerate warnings because I feel as you do – it’s something that will bite me in the butt down the road.

    It’s also more practical then it used to be. Way back when every compiler upgrade was like rolling dice because of all the changes, but that has changed- the compilers are a lot more stable from release-to-release.

    re: Obsolete: that’s a tough call because I think both arguments have merit. This may one of the those situational things. The framework is still new and few products are shipping, so the downside of making breaking changes is minimal. However, this is a luxury that will soon change as .NET gains in acceptance. Once this happens then you will not be able to use that attribute as much as is currently done.

    Perhaps there ought to be another attribute that clearly distinguishes between the two types – one that means that the original code was fine but newer/better/improved versions are available, and an attribute that means that the old code was potentially dangerous and ought to be changed ASAP.

  3. Eric – fair point that not all warnings have to be literally dangerous to be useful.

    David – I like your suggestion; I’ve suggested something very similar (using FxCop to give the feedback). The current attribute is set up to be either a warning or an error. Right now we only use it as a warning.

  4. Sergio Pereira says:

    I think the discussion here is less if having warnings in your compilation id bad and more why the compiler treats the ObsoleteAttribute as a warning. In my (also biased) point of view, I won’t let any warning linger after I compile my code. If it doesn’t need to be fixed soon, the it should not be a warning, but something else. Maybe the compiler needs some sort of "Notes" or "Suggestions" to report during compilation, just like warnings, but less critical.

    Just my $0.02.

  5. Nat says:

    True that ObsoleteAttribute may be very useful to indicate software developers to change their code. However, we also need to consider an environment where a component is developed by one party while consumed by another party. It’s not easy to communicate directly between developers within two parties. In addition to that, the first company might move forward, says, to .NET 1.1 while the other company still uses .NET 1.0. Therefore, the first company might fix the problem, for example, in XML Transformer class as warned in .NET 1.1. However, if they do that, the code might not run correctly at the other company since such API doesn’t exist. This is about backward compatibility.

    In sum, we might need to separate the obsolete into two categories; first, the obsolete methods or types that can be simply replaced by another API in the EXISTING framework, second the API that cannot be changed in the existing framework while the new framework has a workaround which works completely. Or we can somehow provide a better way to handle ObsoleteAttribute by linking it to the version and provide a way to turn off the warning in each signature…. or simpler thing like



    So that you can make the less critical warnings fall off the radar until it is critical.

    You might argue that the first case might not exist very often though as if the code should not be called in the first place… it should not be there…

    my $0.02

  6. Laura T. says:

    I’d prefer that Compiler does what it’s told, compiles and does not complain about my style or choices I make. Compilation is a evil must so it should be as fast as possibile and quiet as possible.

    To judge style (famous L or l) or choices (obsolete, not best) should be left for more analytic tools. During the early stage of development cycle it should not matter and one should not waste cpu or brain time for these things. It’s a matter of training and standards of dev teams and companies to enforce the best practices. Not the job of a compiler.



  7. We have been spending a huge amount of time working on application compatibility between V1.x and V2.0…

Skip to main content