Freigeben über

Rules for warnings and my biased view of the ObsoleteAttribute

  • Artikel

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

  • Anonymous
    October 09, 2004
    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...
  • Anonymous
    October 09, 2004
    The comment has been removed
  • Anonymous
    October 09, 2004
    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.
  • Anonymous
    October 10, 2004
    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.
  • Anonymous
    October 17, 2004
    The comment has been removed
  • Anonymous
    October 25, 2004
    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.

    IMHO.

    Laura
  • Anonymous
    April 25, 2005
    We have been spending a huge amount of time working on application compatibility between V1.x and V2.0...
  • Anonymous
    June 09, 2009
    PingBack from http://hairgrowthproducts.info/story.php?id=3447