Yes but not often.
I usually do that in two different ways, the first one being having a list of all the TODOs of the project (so all tasks in one place) which I generally use for big projects or things where I want to have that kind of structure.
The other being, as you asked, in the code which I use when I want to have the task as virtually close as possible to the relevant code snippet/block (so I don't have to look for it or think about which exact method/function/class/object/prototype it's about). Doing that as Kleo Petrov said in his comment, tend to lead to multitasking, however, I usually have a better idea of what to do (to complete the task in question) when coming back to the part of the code where the task is. As opposed to reading it when I finish a whole set of tasks which may get me to skip that task that possibly needed to be done before others (e.g. adding something to a function to account for a particular edge case that another function can lead to) so whenever I'm working on let's say 2+ functions that are dependent on each other (either by composition, aggregation or by normal dependence).
Using both approaches (although I don't do always do either of them) is good to classify the task where, for instance medium/big tasks would be on the TODO.md list whereas mini/small ones would be in the code.
The good thing with IDEs, is that most of them would track the @TODO comments and point them out when needed so I usually don't forget about them.