Jason Zander is Corporate Vice President of Development for the Windows Azure team at Microsoft.
Learn more about Jason.
More videos »
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:
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.