Poll: If TODO comments were more "visible", would you resolve them faster?

Question

One of the known problems with //TODO comments is that they tend to get "lost in the code" and are often never returned to.

One usually finds them when searching the source code, or when actually going through the IDE task list (e.g., in Eclipse).

Of course, bug reports are easier to find, but research shows that developers aren't really winning to open a bug report for every little thing.

So my question is this: suppose that you're using the IDE and:

1) Every //TODO comment is highlighted better (e.g., surrounding box or background) instead of the current low-key color and small icon in the side.

2) Every call to a method that has a //TODO comment is highlighted in some way, to let you know that the code you are looking at depends on something unfinished.

Would that be useful and make you more likely to fix problems (to get rid of the marking or to make sure your code doesn't depend on anything broken), or would that annoy the hell out of you and make you turn the darn thing off?

[EDIT: My question is directed at those who do use //TODO comments. I am well aware of their evils, but research does show that many people do use them because bug reports are too expensive/visible] and because they plan for these comments to be transient.]

Answer 1

in .Net, I have R# ... which has a handy To-Do Explorer ... which shows me all of my todos, as well as other things.

Answer 2

Our API docs are auto-generated into HTML from source code comments, and (if properly formatted) todo comments are listed in a todo page. They are still generally ignored.

Answer 3

Actually, I don't put TODOs in my source code after reading the Gary McGraw security books. Apparently, people who want to exploit your software toggle in on "TODO", "FIX", "bug", and "XXX" tags which are often used by in-code task identification systems.

Instead, I keep a to-do list separate from my source code.

Answer 4

Honestly, I don't think //TODO's are a good bug/feature tracking system at all. It is inherently flawed and difficult to keep track of. I think you should use a true Feature/Bug tracker and put the issues into that system. I even think Notepad is better than inline //TODO's.

With that said, I still occasionally do this myself. In visual studio you can view your task list easily enough but really.. I prefer a dedicated repository for these sort of things.

So, no.. I don't think increased visibility would fix the flaws of the inline, comment TODO system.

Answer 5

Before I do a release, I always check all my TODO's. So no, I don't need any additional visual hints to help me resolve those items.

Also, I hate having additional "decoration" in my code, such as highlighting or underlines, because this changes how I read the code and can cause me to miss bugs or make it slightly more difficult to see control flow by drawing my attention to specific lines.

Answer 6

If you're developing in Visual Studio you can view your TODO: list from your IDE in a handy list in a dedicated window. That's what I do. It's a lot better than trying to remember to search for all of the TODOs in your code.

Go to the menu bar and select 'View' > 'Task List'. When the window appears, notice you can select a drop down box that has two options: 'User Tasks' by default and then comments. If you select 'comments', it will list all comments, the location and line number where you have written the comment prefixed with TODO:

You can also configure your IDE to include others like HACK if you want. It's a pretty great feature to have if you want to be able to go back to some piece of code later that you got "working" but need to correct later.

Answer 7

Simply, whether it's a todo or anything else, if it's not in the Issue Tracker, it doesn't exist. Use the issue tracker like source code control, as it gives a better higher level view of the project than random comments splattered across source code.

Answer 8

I use an extended comment marker ("//#"), which I modify my syntax highlighting rules to highlight, and regularly grep my repository for.

I copied the idea from a coworker 10 years ago ("--#" in Ada), and I've trained myself pretty well to see and act on them. Doing the syntax highlighting in the editor helps, but you have to make it part of your normal workflow, or you'll train yourself to ignore it, no matter how visually distinguishable it is.

Answer 9

I wrote a script to make TODO: comments appear as warnings when I do a build in my IDE (Xcode). It just takes the output of grep and reformats it so that the IDE identifies it as a warning.

I don't know if it makes me resolve them faster, but it keeps me from releasing a build without at least being aware of them.