You have almost converted me from using TODO. I typically place a "Note:" when there's code that is hacky but not obviously so, to provide context. I also make sure to provide a link if some kind to a relevant issue tracker.

But a TODO is something different. It's for prototype code, where I don't even know if the feature is going to stick around long enough for the hack to warrant fixing. It says "don't worry about just deleting this whole thing outright and starting fresh." It's graffiti to intentionally make the code uglier, so it's not confused for being part of some larger design. It says, "hey, so, I didn't actually expect this code to survive, but since you're here reading this, it clearly did, you're probably working on something related to it, and you might want to know a few things upfront because it's not going to go the way you think it should go."

"Note:" comments are perfectly fine. On the other hand, I've seen at least three distinct definitions for TODO in this HN thread:

- TODO should be a note about behavior.

- TODO should prescribe a small fix.

and yours: TODO should mean "don't worry about deleting this".

These different interpretations and potential confusion they would create make even a stronger argument against TODOs.

I'm afraid "don't worry about deleting this" was poorly phrased...but your point still stands

Exactly, TODO comments are basically noise. Nobody goes through code explicitly looking for them, and by the next time someone needs to modify that code the TODO is very likely obsolete or just confusing because of how much the rest of the code and circumstances have changed.

In code reviews I always encourage replacing TODOs with a ticket or just removing them. I just can't think of any time when a TODO was actually useful.

As a developer, seeing a TODO in there is a non-issue. I appreciate the context from the previous developer and I don't feel any sort of pathological urge to stop what I'm doing to fix that TODO (unless it's actually relevant to what I'm doing, in which case, I appreciate that it's there). The way you're phrasing things suggests that you don't trust developers to manage their workload. Is that the case?

Also, the notion that developers shouldn't be involved in "business information" is a non-starter to me. They should absolutely be involved, it's a big part of the job. If they wrote it as a TODO instead of adding something to the issue tracker, they probably thought that it was an issue that did not need to be raised to non-technical people or project managers. You know how managers talk about "managing up" all the time? Dev's do that too.