ToDos in code and my all time favourite thing in .Net ever of the week

In a recentish blog post, Jeremy Miller discussed his favourite way of marking up ToDos in code in such a way that it is very very obvious that there is still work to be done and where it is needed. Whilst I like the technique it is entirely dependent on working with unit testing frameworks and in my current role we sadly do not have any sort of testing in place. I'm hoping to try and rectify this, but for the time being I need a different option. This leads me to the first bit of technical stuff in my blog. Hooray.

Operating outside of TDD I also find that ToDo's close relative of slipping quick hacks into code to ensure that a particular path will be followed during my manual testing can be very handy. Both of these are things that need to be removed from code as soon as possible, they desperately shouldn't make it into production code, and should be as obnoxious as possible to make them easy to find and remove whilst being a very noticeable smell when they are present. Adding debug or trace output can easily be lost if the program is generally chatty and requires that code to execute to even show up. Just commenting it requires me to remember to search for issues that need removing, and a little typo could lead to problems being lost forever.

The answer that I have found to this focusses around the Obsolete attribute.

[Obsolete("HACK - This call is a hack that should be removed prior to release")]
public void Hack(string message)
{
Debug.Print(message);
}
[Obsolete("TODO - This marks a placeholder for work to do")]
public void ToDo(string message)
{
Debug.Print(message);
}

When compiled this will leave warning messages anywhere that the routines are called which is suitably obnoxious unless you have a project full of warning messages and that is a whole nuther problem. A double click of the warning message takes you straight to the code that called it meaning that locating the temporary hack or ToDo is quick and easy, and the mix of intellisense and compilation errors means that you're not going to lose something that you mistyped as TiDo or similar.

Marking the code as Obsolete feels a little kludgey, but it is the only attribute that has this behaviour and it can't be derived from to create something that fits more naturally. Of course, due to the temporary nature of how the routines are used there is an argument that any time they're added they are instantly obsolete, so I can cope with the slight dodgyness.

As such things are very useful, especially in an environment that doesn't allow for TDD or effective OO practices (most of the code for many of our company's apps is situated in the same file as the ASP markup, not even in an overly crowded code-behind, just with the markup) hence this is my all time favourite thing in .Net ever for this week (and in fact the last few weeks from when I started using it)