Use a Formal Review Process
It works, if this is indeed part of a process that all members need to follow.
Meaning that when a code review is initiated, it's expected that there will be comments, and that these comments MUST be acted upon, either by discussing and discarding them or by implementing a change.
Link to your Issue Tracker for Follow-up Actions
If you want to be extra formal (which might be required depending on your environment and audit procedure), you could even open new tickets in your tracker for each required action, which can then be closed either as fixed or rejected with the necessary comments for clarification. If further reviews are needed, then open a review request (assuming you have a tool to do so). Code changes need to be verified, preferably by the original reviewer.
Beware of Crippling your Codebase
If that's not part of your process, then such comments are likely to become akin to dead-code or code-rot, and possibly leave more interrogations than answers behind. So if you don't have a formal review process, you might want to avoid those, except if it's for personal tracking and you keep a tight tab on them. These should preferably have a short lifespan, and be acted on quickly. Or they shouldn't be TODOs and be actual code comments about what's wrong and needs to be changed if it's a major change, to serve as a warning to other developers.
I give additional reasons against (in the general case) inline action tags and useless inline comments in this answer about the use of non-documenting inline comments.
In fact, if you can and have the right tool for it, I'd suggest you avoid these for code reviews and use a code review and code annotation tool that allows to separate this from the code.
Rely on Code Review and Code Annotation Tools
It's a tricky decision to make, as sometimes you'd prefer to have everything with the code in your SCM (in fact there's even a code review tool for Eclipse that stores review comments in text files along with the source files, for instance). But for larger teams and projects it works quite well to have dedicated tools to annotate code and have extended discussions recorded somewhere, within the context of your code. You can also link them to current code-reviews, to tasks, or directly make comments on a file or a changetset.
In the screenshot above, for instance, you can see a threaded discussion directly inlined with the code to highlight a concern, and this is being done as part of a formal core review item (with the ID
CR-ANERDS-8) relating to an open ticket (with the ID
Here is an example of a use case where you create a new ticket to be able to track future follow-up actions on the review. The reviewer can easily create tasks as he sifts through your code and notices shady spots.
There are numerous tools for this, but personally I tend to find FishEye and Crucible above par (and obviously working great hand in hand with JIRA, or even Confluence to link to even more detailed docs if needed).