I was talking with Scott Baldwin just a few moments ago about some of work items that are currently in our TFS repository in the current iteration and whether they should be pushed into the next one. He said that a few of the work items are actually follow ups to FxCop warnings that he suppressed that he wants to come back and remove later.
A good example of the need to do this is CA1020 (Avoid namespaces with few types). Let us suppose you are a bit of an FxCop nazi and you have set all the FxCop warnings to errors. This little charmer (CA1020) will stop you dead in the early phases of your project while you are still buidling out your class libraries – so you effectively have to suppress it. Of course, you then create a work item to revisit it in a future iteration, but it can sometimes be difficult finding that code again.
Maybe there is a better solution? Some WikiWikiWeb implementations support this concept of “fading tags” where you can mark something as new, but in the future it will just revert to a standard rendering. A good example of this is the FoxProWki (thanks to Andrew Coates for pointing this feature out to me years ago).
Anyway – I thought maybe we could apply this feature to the [SuppressMessage] attribute in FxCop. What if we tagged suppressions like this:
[SupressMessage(…, Expires = “31/10/2006”)]
This way, when FxCop goes through and runs, if it strikes a suppression which has expired it ignores it. This way our code would scream at us when its time to look at it again.
Some people might not like this feature so you would need an option to “ignore expiries” on a per project basis for when people inherit someone elses code. They would also be able to do what Scott is doing today and create work items – but not everyone has a defect tracking system supporting them like we do.
What do you think?