I think it makes sense to refine the levels a bit more. We use FIXME, TODO and OPTIMIZE in order of decreasing importance.
- FIXME should really not even be committed, except in a proof of concept
- TODO should be fixed eventually, preferably before release to production
- OPTIMIZE is a "nice to have" that gets fixed on a quiet day
Furthermore, TBD (to be done) indicates where new expected functionality is expected to appear, deliberately different from TODO because the JetBrains editor flags TODO / FIXME for confirmation before commit, and will ignore TBD.
I was actually just thinking about implementing this type of importance based flags.
In addition to these, I'd like review stubs. Something like:
- REVIEW: can this be done better?
I'd like junior devs to be able to note things as they're thinking about it, not try and remember it later during review. Especially since there may be nothing wrong with the code, it may be as good as it can get[1], so a reviewer wouldn't catch it. Though, I'm mildly concerned about cluttering up code. I suppose you could just remove them on the fly down the line, since they made it past review and etc.
[1]: As good as it can get.. that the reviewer knows of heh
- FIXME should really not even be committed, except in a proof of concept
- TODO should be fixed eventually, preferably before release to production
- OPTIMIZE is a "nice to have" that gets fixed on a quiet day
Furthermore, TBD (to be done) indicates where new expected functionality is expected to appear, deliberately different from TODO because the JetBrains editor flags TODO / FIXME for confirmation before commit, and will ignore TBD.