As the saying goes: "This is a topic upon which many intelligent people disagree"
Pros
I came to my current position a firm believer in both FIXME and TODO comments in code. They seem entirely helpful, in that they're brain-dumps of the context you have in your mind while you're doing the code for tweaks not urgent, but important to deal with at some point.
Also, back in the day, you might not have anything aside from version control, and in the worst cases, all you may have is a shared directory of code. The code was the only place to keep and track issues in context.
Last, people may say: "Log that in JIRA (or similar)" but not everybody reads those. Especially if you're working on F/OSS, people may not read the bug tracker, but they definitely read the code.
Cons
Yeah, sure. They "read the code" but what if there's a million lines? If I grep a codebase and see 5000 TODOs I have no way to know what to tackle first.
More bluntly: TODO comments get lost, get out-of-date, and they effectively become noise and technical debt themselves. My first checkin here had several 'TODOs' about things I noted in the codebase (algorithmic issues, internationalization problems, etc.) and the code review feedback was blunt: "Log these as issues in our bug tracker. Don't put these in the codebase."
That's pretty much what I do now. If practical, a bug tracker with code links to the affected code surfaces issues much better from process perspective. Then, the TODOs can get prioritized and dealt with in your sprint.
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.
As the saying goes: "This is a topic upon which many intelligent people disagree"
Pros
I came to my current position a firm believer in both
FIXMEandTODOcomments in code. They seem entirely helpful, in that they're brain-dumps of the context you have in your mind while you're doing the code for tweaks not urgent, but important to deal with at some point.Also, back in the day, you might not have anything aside from version control, and in the worst cases, all you may have is a shared directory of code. The code was the only place to keep and track issues in context.
Last, people may say: "Log that in JIRA (or similar)" but not everybody reads those. Especially if you're working on F/OSS, people may not read the bug tracker, but they definitely read the code.
Cons
Yeah, sure. They "read the code" but what if there's a million lines? If I
grepa codebase and see 5000 TODOs I have no way to know what to tackle first.More bluntly:
TODOcomments get lost, get out-of-date, and they effectively become noise and technical debt themselves. My first checkin here had several 'TODOs' about things I noted in the codebase (algorithmic issues, internationalization problems, etc.) and the code review feedback was blunt: "Log these as issues in our bug tracker. Don't put these in the codebase."That's pretty much what I do now. If practical, a bug tracker with code links to the affected code surfaces issues much better from process perspective. Then, the TODOs can get prioritized and dealt with in your sprint.