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…
The Linux codebase has over 3k TODO comments, many from over a decade ago
81–90 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#82Earlier 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.
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
#83In 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…
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
#84Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#85I 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".
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#86I 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.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#87Earlier 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.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#88I 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.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#89Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#90You can either note them in some way as they emerge, or ignore them and keep your code tidy of such notes.