With respect to TODOs and FIXMEs in the comments, I use them to mark places I know I will need to go back. Before calling a piece of code done, I grep for TODO and FIXME to make sure I haven't left anything unfinished.
I agree. I use TODO indicators as a code smell for things I forgot to add before making my pull requests, but I also see them as valuable reminders for future needs.
Sometimes there's a quick-but-less-generalized way of solving something, and you know there's a more elegant way of doing it, but for now you need to get something working/fixed and don't want to make sweeping changes.
Your immediate change might be to add a way for users to see that X is finished. A useful TODO message would be something which explains what you're doing
# Tell users when their Solve-My-Foo is done
# (Currently done in an ad-hoc way)
# TODO: Add a notification infrastructure so that
# arbitrary components of the apps can present
# notifications of Important Things
# e.g.:
# - celery job is done
# - a thing you've subscribed to has changed
# - a report/download/etc is ready to be retrieved
Building such a system might be overkill right now, if this part of your system is the only one that uses it, but a TODO message helps me see (the next time I make changes to it, or try to extend it, or use it as a template for reimplementation elsewhere) that there's more than one place we need this feature, and so it might make sense to plan/do those more comprehensive changes.
Sometimes there's a quick-but-less-generalized way of solving something, and you know there's a more elegant way of doing it, but for now you need to get something working/fixed and don't want to make sweeping changes.
Your immediate change might be to add a way for users to see that X is finished. A useful TODO message would be something which explains what you're doing
Building such a system might be overkill right now, if this part of your system is the only one that uses it, but a TODO message helps me see (the next time I make changes to it, or try to extend it, or use it as a template for reimplementation elsewhere) that there's more than one place we need this feature, and so it might make sense to plan/do those more comprehensive changes.