if they exist only in your local branch I see no problem. I could pick any style of development you want. But when it goes to 'master/mainline/trunk' there should be no such thing. What if someone changed the code near that comment. He/she didn't do what's written in the TODO, and the change is substantial and this TODO doesn't make any sense. But the person changing it is to shy to remove your comment, because it is something you wanted to keep as a reminder for yourself, don't you? The TODO may become irrelevant because of changes in some other parts of the code. There's no way to track who's doing on what TODO comment. And from my personal experience in a large company you never have time to fix things afterwards, including those TODO comments, so they tend to stay in the code forever. I can easily find TODO comments in our codebase created in year 2001. (I think it's the year of import form the previous VCS) And they're all still there and nobody cares for them. :)
So, generally, I'd advise not to leave any TODO comments in the code. :)
But when it goes to 'master/mainline/trunk' there should be no such thing.
There should be no such thing as a technical dept, but it exists in each project.
And as you noticed your old project there are a lot of todos, it doesn't mean that without those
todo comments the project would have more functionality. But I think it is better to write todos and ideas of what could be done rather than nothing. The solution not to have todos is to get it done. For this there should be a scheduled time to work on refactoring.
There are much better and much more reliable ways to track tasks you want to do on your code, that the code itself. :)
In the code you think you're in context of the surrounding code and everyone will understand what you're trying to say. Unfortunately, that's not true. The code tend to change and so does the context. When you enter the task in some external system (jira, trello, bugzilla, you name it), you need to provide all the details of what you have in mind. And yes, you can track it.
Still, there should be no TODOs in the code, they belong elsewhere.
BTW, I never though before, that putting TODO comments in the code is actually a way to hide what's need to be done. I believe no manager will look into the source code for the tasks to plan. :)
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.
Comments are lying. Those ones too. :)
if they exist only in your local branch I see no problem. I could pick any style of development you want. But when it goes to 'master/mainline/trunk' there should be no such thing. What if someone changed the code near that comment. He/she didn't do what's written in the TODO, and the change is substantial and this TODO doesn't make any sense. But the person changing it is to shy to remove your comment, because it is something you wanted to keep as a reminder for yourself, don't you? The TODO may become irrelevant because of changes in some other parts of the code. There's no way to track who's doing on what TODO comment. And from my personal experience in a large company you never have time to fix things afterwards, including those TODO comments, so they tend to stay in the code forever. I can easily find TODO comments in our codebase created in year 2001. (I think it's the year of import form the previous VCS) And they're all still there and nobody cares for them. :)
So, generally, I'd advise not to leave any TODO comments in the code. :)
There should be no such thing as a technical dept, but it exists in each project.
And as you noticed your old project there are a lot of todos, it doesn't mean that without those
todo comments the project would have more functionality. But I think it is better to write todos and ideas of what could be done rather than nothing. The solution not to have todos is to get it done. For this there should be a scheduled time to work on refactoring.
There are much better and much more reliable ways to track tasks you want to do on your code, that the code itself. :)
In the code you think you're in context of the surrounding code and everyone will understand what you're trying to say. Unfortunately, that's not true. The code tend to change and so does the context. When you enter the task in some external system (jira, trello, bugzilla, you name it), you need to provide all the details of what you have in mind. And yes, you can track it.
Still, there should be no TODOs in the code, they belong elsewhere.
BTW, I never though before, that putting TODO comments in the code is actually a way to hide what's need to be done. I believe no manager will look into the source code for the tasks to plan. :)