[coldtea]

>I guess it's probably better that these types of comments remain out of the code itself unless you and your team can practice proper rigor around them, e.g. using prehooks to enforce that no TODOs are left around before committing or merging.

Why? If they're "out of the code" they still can be ignored before committing or merging just as well...

[mercer]

That's a silly statement. Yes, they can be ignored, but perhaps for many people they're less likely to be. That's my experience, anyways.

I could train myself to regularly grep for TODO comments, and perhaps I will, but so far adding them to my actual 'todo app' is much more effective.

[Fellshard]

I'm more likely to write a stub implementation around more complex behaviour that still functions in a minor way first, especially if I want to observe that some component functions even in absence of a complete implementation of another component.

[chucksmash]

My personal layers of organization:

Stubs with TODOs for staking out an interface to be implemented later and the like. Almost always doing "git add -p" is a good way to jog your memory about these. They can be committed but probably shouldn't survive until a merge into master.

A todo file entry for items which are heftier and/or not likely to be returned to today. My todo files are date-based so I try not to add todos for items with a time horizon beyond about three days in the future. I also try to keep these files small enough to actually get through in a day.

A single wish list/ideas file. Keep it in approximately priority order and pull items from the top when you finish your daily todos. This is also often feature-based so a single line might generate a bunch of tasks. Biased towards a personal backlog instead of "just add to JIRA/Trello/whatever" to avoid eternal agile deprioritization hell.

Works fine for me, though of course I'm not out here writing Redis either.