I find it weird to use TODO for something you don't actually have to do. But you're apparently not the only one to do this, and as long as everyone who's working on the same code is on the same page it's fine I suppose.
I think in these same three categories but label them TODO, T0DO, and TOD0, respectively. I like that they look roughly the same when visually scanning through a file but are easy to grep for separately.
Very useful for flagging any O(n^2) that make assumptions about the size of N because N is not expected to exceed a certain size. Especially for when N inevitably exceeds that size.
Documenting it saves the poor dev doing profiling in the future a bit of effort so they can come up with the better solution that you failed to come up with when writing the code.
Often times code has to be written and committed and I don't have the time nor the brains to come up with a novel solution that solves a future performance issue that is not yet and is not expected to ever become a performance issue.
It's just saving the next person the trouble of thinking up and documenting the same approach you thought of while writing the code in the first place. As in, you know it doesn't matter now because the overall thing is plenty fast enough, but you can imagine a future where performance starts showing up as an issue and you wnat to leave a breadcrumb saying "this fruit here, it's a-hangin'".
I take it mostly as "I'm aware that it's algorithmically slow and could become a bottleneck if it scales but I have no time to profile it right now" so you create a note to point this out.
- TODO: will be needed before release, mandatory or else turn into another category. Blocks release.
- FUTURE: will be turned in to a TODO eventually, optional, often architectural
- MAYDO: nice to have, very optional
- PERF: do this if more performance is needed
+
some semantic tags related to domain
Opinion: TODOs are NOT code smells, they accrue around the most valuable parts of the codebase.