Live data from Hacker News

The Linux codebase has over 3k TODO comments, many from over a decade ago

todos.tickgit.com

81–90 of 301 posts

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#81
post #8

Earlier quoted context omitted.

Correct me if I'm wrong but I use "FIXME" for this intent. I keep TODO for stuff actually left to implement.

Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users. Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting…

Open a ticket for that straight away and start working on it immediately. Or 3 years later. Whichever actually happens.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#82
post #43

Earlier quoted context omitted.

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,…

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.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#83
post #47
post #2

In my opinion, any comment prefixed by TODO, XXX, or the like should not survive past the review stage. Either fix the problem immediately or accept that it's going to be wonky forever. Edit: Amending here to avoid replying to ten different threads individually. 1. Long-term improvements should be managed by a ticket tracking system. The code is not the correct place to manage that. 2. Most of the disagreements below…

I agree and don't understand people who downvote you as a punishment for expressing your opinion. A TODO item is missing significant business information: date, priority, severity, risk, impact, applicability etc and leaves all those assessments on developer's shoulders who shouldn't have to deal with it at all. As a matter of fact, every time a developer encounters a TODO around the change he did, it suddenly become…

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.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#85
post #61

I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

> This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization. I assign the same meaning to TODO or FIXME markers but a lot of people see this is as a measure of poor quality so instead I write regular comments of the form "this could be made better by doing X and Y".

That may work but I find those comments tend to get lost over time. TODO/XXX/FIXME support are built into IntelliJ which makes stuff like that super easy to find. If some random dev looks and decides its low quality because of those words...well I don't care because its a silly metric to judge on.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#86

I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

For small projects without issue tracking, I use TODO for this iteration (or soonafter), and WISHLIST for "would be nice" future optimizations.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#87
post #63
post #55

Earlier quoted context omitted.

TODO, as the name implies, should be things that must be done. Anything aspirational could be left as a mere ordinary comment. Personally I hate TODOs and only see them as temporary things to act as placeholders for the correct code. At some point, I will go through all todos and clear them.

> TODO, as the name implies, should be things that must be done. A lot of people use them for things that "could" be done.

yep, TODO is for things like possible optimizations or improvements that are known, and FIXME is for things that are... functioning, but incorrect by some reasonable definition. (YMMV)

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#88

I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

[deleted]

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#90
Most anything you do, in general, will fork off into many branches. Some being required dependencies and many others being tangential improvements or generalizations.

You can either note them in some way as they emerge, or ignore them and keep your code tidy of such notes.

Post reply on HN