These are the worst. They're explicitly indicative of a problem in the code. There are only two reason that ToDo slips into your repository. Either the developer who wrote the comment:
- Was not thorough enough to finish the job or,
- Not brave enough to bring it into the light of day as a Technical Debt backlog item.
Those two rules both provide caveat for using ToDo comments.
The latter case presumes that there is an issue tracking system. If the team you're working in does not have one of these then you should probably stop reading blogs and get to fixing that.
In the former case is see ToDo as acceptable for documenting unfinished work while it's on going. In this case the code should be rejected in peer review for any ToDo comments, stopping them being a smell in production code. Even better than peer review is having a linter/style checker break the build because if there are any ToDo comments in the code, stopping as soon as they get into the repository.
If your process is mature there is no excuse for having ToDo comments in your code.