Judging by the nature of the TODOs left in both my open- and closed source code, I'm not convinced that this is entirely good advice.
Usually the reason for me to leave a TODO is when something really minor doesn't work right and making it work would more often than not be a huge undertaking or at least require quite a bit of thought.
If the thing that didn't work right was important, I'd add a bug to the tracker in order not to forget it. If it was easily fixable, I'd fix it then and there.
This leaves these TODOs to be tasks I would not want a newcomer to the code base to tackle, because the first solution they would come up with is likely incorrect, so all the amount they'd put into fixing it might end up in vain.
That said: maybe others use TODOs differently. This really is judging from my own experience.
You're not far off of how we work. TODOs end up in two categories: minor things I need to do before a commit, and major things that require some huge chunk of code to be [re]written but maybe aren't "features" and don't need official documentation. We see the latter more often in new products and not in mature codebases.
(Then there are the orphan TODOs - such as one strange ??TODO?? in some code I inherited that has no good documentation (just a vague reference to another class) but looks too important to remove. One of these days it's getting deleted.)
I know when I write TODOs, it's usually because my solution isn't clean or misses an irrelevant edge case that may become relevant if requirements change.
I generally use "FIXME" if it's actually something that needs to get corrected. TODOs are more like you describe -- nice to haves (perhaps), but too much work for the benefit.
Well something really minor is exactly what the students we was talking about are looking for. This is excellent advice for me, since I am new to web development and usually get so intimidated by the cheer volume of code I am exposed to that I abandon it.
I think he is saying that TODO are often not that simple because many programmers use them for something that works, but needs a conceptual change - which can be a major task.
It depends on the project though. Other projects may rely more on an issue tracker.
Either way, don't let it stop you, most open source projects are glad to have help!
True, but I think it can go both ways. I've used TODO a few times just to remind myself about something fairly trivial that I didn't feel like compiling/testing again before I commit (ie. cleaning up code, small optimizations, etc.)
I think the general advise in this article is good, though. By searching TODOs, I'm sure there will be many non-trivial fixes that will be found. But at the same time, I'm confident that it's a good way to find little things that have been forgotten about in the code.
Usually the reason for me to leave a TODO is when something really minor doesn't work right and making it work would more often than not be a huge undertaking or at least require quite a bit of thought.
If the thing that didn't work right was important, I'd add a bug to the tracker in order not to forget it. If it was easily fixable, I'd fix it then and there.
This leaves these TODOs to be tasks I would not want a newcomer to the code base to tackle, because the first solution they would come up with is likely incorrect, so all the amount they'd put into fixing it might end up in vain.
That said: maybe others use TODOs differently. This really is judging from my own experience.