How to manage @todo programming stuff ?

Question

For many years my code was full of this kind of comments :

//TODO : Add ...
...
/*
 *TODO : Fix ...
 *
 */

Now I think to create my own @todo javadoc annotation ... but before doing that I want to know if do you guys have better way to manage your todo programming stuff ?

Answer 1

For small tasks such as my usual //todo I use local tasks in Eclipse Mylyn, for bigger tasks (even if I think those might be called features or bugs) I use Trac; if you find your code full of TODOs it's time to get a ticket management system.

Answer 2

Your IDE (Eclipse, NetBeans, ..) has a tasks plugin, which detects all TODOs and shows them in a list. In Eclipse it's Window > Show View > Other > Tasks

No need to write your own annotation.

Answer 3

For vim there is also this Tasklist script, inspired by Eclipse's task list, which scrapes for TODO, FIXME, etc. in your text files and displays them as a list in an extra buffer (see screenshot).

Answer 4

I basically use three systems for different kinds of TODO items:

• Paper notepad for short-term items (like today or this week)
• TODO comments plus IDE support (e.g. Eclipse Tasks view) for smaller, longer-term items
• Issue tracker like Trac plus IDE support (e.g Mylyn) for more complex, longer-term items

Answer 5

Maybe you can use find and grep to search for those keywords in your projects

Answer 6

problem with todo flags is the same as with warnings (e.g. java compiler, checkstyle). if they appear to often, you will ignore them. in your case i would track them through a report by a build-system (e.g. maven or ant). at the end of each iteration you should make a rule, that the number of todo flags decreases.

less todo-flags means:

• solving them
• delete them because they got obsolete (which happens often if you never tidy up code)

generally don't use todo flags for all tasks. for me they are just little reminders or refactorings-todos. bigger tasks should always be tracked by a ticket-system (like trac or jira).

Answer 7

Maybe Doxygen can help you?

Doxygen recognise those ///@TODO:s and creates a list with them.

And since Doxygen can use Javadoc style comments, I guess it is kind of easy to try it.

Answer 8

If your TODO statements are bugging you that much and causing you that much angst when seeing them I'd write a small script in the build process that detects and fails the compilation. Have it fail in the same way that it fails on warning statements.

Answer 9

I use FIX! instead of TODO. The number of exclamation points indicates the priority. IntelliJ lets you set up custom filters for these, so I can look at level-3 "FIX!!!" comments and tackle those.

Answer 10

I would not use a @todo javadoc annotation because IMO it should'nt go into the documentation.
Documentation should be public, not ideal for TODOs.
TODOs should also go near the code they relate to, an advantage of using comments.

Answer 11

If you are using Maven, you could use the taglist-maven-plugin to scans the source files for tags (any tag you want, this is configurable) and generates a report on their occurrences.

The Taglist Maven Plugin generates a report on various tags found in the code, like @todo or //TODO tags

But tracking tags is the easy part, fixing them is a bit harder and takes more time :)

Answer 12

TODO statements carry the risk of being left in the code forever, which is bad because // TODO elaborate answer

Answer 13

TODO is fine in a small team, but if you open-source project or widen the developer access in any way, the other variants like TO_DO, fixme, XXX, NOTE, HACK, bug, "your_defect_tool_here" and so on need scanning for anyway. A bit heavyweight, but my TODO protocol would look like:

TODO:yy-mm-dd:author:your_comment

Lastly make the comment you do leave strategic, not a design statement or opinion.