From my experience TODO tends to stay in the code forever. I only use them while I'm refactoring some code or if I know I'm going to deal with them within a few days to complete a feature. As a matter of fact I'm now in the midst of migrating a project from Objective-C to Swift and I'm using a lot of TODO, but I know they'll eventually go away.
The problem with TODO is sometimes you use them when you write something in a hurry, you feel is not optimised and you leave a comment for the future self to refactor that particular piece of code. You'll hardly find time to deal with it, and the TODO will stay there so just avoid adding it in the first place.
Exactly, marking your todos with your name and date helps you and your team to keep you accountable. And making sure you have a ticket in your tracking system of choice ensures that nobody forgets them. And by calling them out in a code review and asking for the todo to be resolved before merging prevents the todo from ending up in your code base completely.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
From my experience TODO tends to stay in the code forever. I only use them while I'm refactoring some code or if I know I'm going to deal with them within a few days to complete a feature. As a matter of fact I'm now in the midst of migrating a project from Objective-C to Swift and I'm using a lot of TODO, but I know they'll eventually go away.
The problem with TODO is sometimes you use them when you write something in a hurry, you feel is not optimised and you leave a comment for the future self to refactor that particular piece of code. You'll hardly find time to deal with it, and the TODO will stay there so just avoid adding it in the first place.
Exactly, marking your todos with your name and date helps you and your team to keep you accountable. And making sure you have a ticket in your tracking system of choice ensures that nobody forgets them. And by calling them out in a code review and asking for the todo to be resolved before merging prevents the todo from ending up in your code base completely.