Even if no one gets round to fixing them, TODOs and FIXMEs can provide a small glimpse into the thought processes of whoever was writing the code and perhaps more importantly, give you a sense of what pressures/priorities the project was (and possibly is) subject to. (Especially if there are no corresponding entries in the issues tracker of the project).

I always create a new todo.txt file on every single project.. it's kind of a habit now :P

Personal projects yes, work projects I'd put stuff into the backlog.

What are thoseeee?

Always. Usually for short term things, to remind me of what I need to get done. My editor highlights them so they stick out as I look around the code base. I also use NOTE for long term information. I also like to sign my comments, TODO:(rob loranger) ... then people know who to talk to even without version control histories.

I didn't used to, but the software from JetBrains (and possibly other IDEs?) will notify you if there are any hanging around when you go to commit code and I find that it's a good reminder that I had some notes laying around. It won't stop you from committing, but it does give you an opportunity to review before you do.

I did one time and it worked - it never stopped bothering me until it was gone :/

Too often what I do by accident is leave in a console.log() for debugging and forget to take it out until I'm showing somebody the website later and see the evidence in the JS console hehe

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.

I use ##TODO in my code to mark places for future refinement or edge case handling. For example, I might use a linear search to get an algorithm working for testing. If all goes well, then I will probably replace it with whatever is most suitable based on real metrics. Same with edge-cases, I might think of one, but haven't yet written the test nor reasoned about it.

I add them daily and remove them annually. In large projects they often represent dependencies on other projects/systems that, once completed, will allow for more elegant refactoring of the code at the point of the TODO. For personal exploratory projects where I'm pursuing a slice through the system they're an indicator of something I should think about eventually.

I have used VS exclusively for years, so I use // TODO: comments to keep a list of areas to look at refactoring later, fix (I may be on a different item at that moment and don't want to lose focus), etc. Todo comments have also helped me diagnose a few problems recently, where a past developer had planned on optimizing a function and never go to it, and it was time. It merely helped me see an area of concern that's carried on, where he simply said // TODO: this could be an issue eventually.

I do, and it's generally in an area of the code that is about handling an error that should never happen. Fortunately, Aptana Studio shows me all of these in a task list, so it's fairly easy to manage.

I also add SMELL to my code. That's a keyword that means that the code is commented out for whatever reason (usually because it was in use at some point, but no longer, and I add a comment to it, such as: delete after <insert date here> date. Then, a couple times a year, I go back and remove the stuff making up code smell. I do like to keep my code as clean as I can. Hard to do when in a time crunch, but this method works for me.

We do, and instantly turn them into issues.

We use a GitLab private group. For each new TODO, FIXME, and XXX lines a script in the commit pipeline opens a new issue. When the comment is removed, it also adds a comment to that issue, so devs can look at it, and close the issue if it is actually solved.

We, as a team, generally think a TODO comment is a good thing. It marks the code as "works for now, but this might change if the stars align". Leaving them there forever, however, is a bad thing.

We used to to have a shame wall that displays all TODO comments by author, ordered by age, if the comment got old (ie. a month or so). As that wasn't helping, we created this issue opening script (the shame wall is still there, though.) It works fine.

Yes, but our rule is that a @todo will only be accepted in a code review if there is an accompanying ticket in JIRA, and that ticket number is referenced in the @todo. For open source, I'd suggest something similar -- always accompany @todo with a GitHub issue, for example.

Yes, i use TODOs a lot, not for remembering things in 5 months or 1 year, but to remember things that I need to finish in the next 5, 10, 15 minutes. This way I can keep my head more clear. Example:

if(imFull) {
// TODO: dont forget to add a call to the api clear all
} else {
// TODO: eat till im full
}
// then i continue with some random stupid code full of bugs and no tests

When i reach the end I go back and start solving each TODO .. and adding more TODOs... and more bugs :)

For work projects, I have the team take TODOs out of their code and put them into our own list in the project management system. That way, our technical debt stays in front of the engineers & project managers in an ever-growing list. Every time there's unused hours at the end of the month (and it happens), we can prioritize the items on that list and spend time on some of those items.

My personal projects are usually managed in Github so I create issues to track them.

The nature of comments and TODOs

Adding TODOs to your code is a double-edged sword. While they provide valuable informarmation, they're often simply left to live in the code as a parasite. The idea of TODOs and FIXMEs is to provide some context to other developers and to yourself about a missing or not working code block, which will be eventually refactored and fixed. It all seems fine if only the developers are responsible enough and have the time to made the changes.

In a perfect world, a TODO should and would be handled in a matter of days, maximum. But that's not the case. Developers are preoccupied with their own tasks and own problems. To be able to do the problem with satisfying quality, one developer is tasked with, he should concentrate on one task only. We all know that multitasking is conterproductive, and TODOs are a catalyst for multitasking and context switching.

TODOs are not all black

While TODOs can be seen as a non productive practice, they can have positive influence on developers if taken with proper responsibility. We all were in a situation, where presured by time and deadlines, we decide to finish the task using the fast and non-optimal solution, in exchange of introducing technical dept. Technical dept is a necessary evil, an assessed risk, which we dedicate time to remove periodically in the future. How can you track your technical dept? With TODOs and FIXMEs.

There are tons of tools to track TODOs in the code. Almost every IDE has an integrated TODO tracking. Webstorm, for example, will even warn you before commit, that the code has an unresolved TODO or FIXME comment.

Personal preference and dedication

I have to confess - I stopped using TODOs. I prefer to compensate on time and deadlines in favor of complete and production ready code. I tried to find a balance between them, but it didn't work (for me). So, choosing between shipping incomplete code just in time or taking a day more to refactor and finish the task, I would choose the second in 99% of the time.

That doesn't mean everyone should stop doing it. It may work for you, but remember - dedicate part of your time to handle them and make it a habbit.

I tend to add a lot of TODOs in my code; as Marco has pointed it out, these are features/additions/probable restructures; which either cannot be reasoned out at that point in time, or the ones which have not been factored in the initial time budget before something is to be shipped, or both!

I generally do find time to go back and do the corresponding additions, or refactors; or edit/remove those TODOs which are deemed unnecessary.

In a large scale project, especially when you are working in a team; it is inevitable for some TODOs to be left out; you can use git blame to contact the corresponding author to make the necessary changes, during a code cleanup session!

Yes, I do add todos to my code. Those are features, which increase stability, security or are nice-to-have features I came up at that moment, which are not in scope for initial release. After the release, however, I grep all todos and either work on them or file issues in the tracker (or do both)