Hacker News Reader

Comment by dws | Hacker News Reader

The codebase that has no TODOs has no vision of its future.

I don't think TODO should be utilized for future functionality but for improvements in existing functionality or things that are missing in the current implementation you can live with short term.

Your vision of the future should be in a bugtracker, not in code comments. TODOs give you a vision of what you would do if you had a few more hours. A bugtracker gives you a vision of what you would do if you had a few more years.

(Where do you put "TODO: Learn tool X and rework all of this to be completely different using that tool if it makes sense" or even "TODO: The program crashes at shutdown with a double-free, but I don't know which line of code had the extra call to free"?)

I have completely the opposite opinion! Any bug in the bug tracker hanging around "in a few years" should* be closed. Comments should* persist while the source code issue to which they refer remains remarkable.

*it's fun issuing such rulings.

Closed bugs are still easily searchable in just about any bugtracking system, whereas deleted code is much harder to dig up (you're less likely to even look for it, and if you do it's harder to find the relevant parts).

I agree that closing bugs you don't intend to act on soon is reasonable; I disagree that this makes it not worthwhile to have filed it.

FWIW I also agree that todos specifically about certain lines of code, i.e. todos that will become irrelevant if the code is rewritten at all, should be in code. The limit of that is probably roughly "TODO return the right error subclass". Even "TODO pass more information into this function" is probably past that limit, since it affects at least two spots in the code.

It should just follow a retention policy. If no action on it in the last 12 months just automatically close it.

Otherwise issue tracker has thousands of items that the team will never realistically work on.

Reply on news.ycombinator.com