I'm not a big fan of comments in code. Especially after few years of writing in Objective-C, which can be very descriptive in its nature.

Every time I want to write a comment, I think if what I'm trying to say could be expressed by the code I'm commenting. Or if case that I'm describing could be handled by the code somehow, by handling nil argument, using id with protocol, provide different method or class.

It's much better to write code than comments, because even if the code is temporary, you have better chance of finding the time to refactor the code later, than to go through some comments and check if they still apply.

Comments do get old really quickly and are often ignored. The more comments you have, the more they become background you ignore. Syntax highlighting doesn't help here either, since in most cases they are dimmed. And for a good reason, you're writing code not comments.

Recently I had a short argument weather it's better to use // TODO comments or #warning. A good point was made, that warnings should be treated as errors. A point that I agree on. But for the same reason I believe that #warning is a good tool to make a TODO statement. Something might not be an error from code standpoint (unless it's an empty method), but it might be an error from implementation standpoint. The feature you're working on isn't finished (in the scope you've planned), until you "fix that error". Mark it as such with a warning, as a reminder for you and your fellow developer to not forget about it, before closing the pull request.

And if it's not the case, if you're just seeing a place to refactor, want to get back somewhere after some other code is ready? Create a ticket in an issue tracking system of your choice, put it in the backlog somewhere and describe it however you like and wait for better times.

Remember - comment with TODO: is a message from your present busy self to your future busy self, thrown in the ocean of code, hoping they both meet at some point in time.