How to manage @todo programming stuff? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve 开发者_高级运维this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this 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 ?

---

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.

---

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

---

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

---

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.

---

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.

---

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).

---

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.

---

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.

---

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

---

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).

---

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 :)

---

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.

---

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.