[Fellshard]

Ostensibly, this is what TODO comments have always been for.

Realistically, 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.

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

[thecatspaw]

personally I just write the function call, wait for my IDE to complain that the function doesnt exist, press command enter to have it generated with a throw new NotImplementedException().

works well for me, gives me the illusion of a working api, and I get autocompletion.

This requires you to give your functions well thought out names though