I guess all the FIXME and HACK have to be addressed first :)
The Linux codebase has over 3k TODO comments, many from over a decade ago
181–190 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#182Earlier 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.
Also, there are things that "must be done" only if the code is extended but it may be perfectly fine as it is at the current state. So I add a TODO when I see that there will probably be the need for refactoring in the intermediate future, but there is no need in the current code base. That is a TODO that is triggered (to become a "true TODO") when that code is touched again, but it remains (justifiably) inactive for now.
The reason I use not just a comment is what others here already said, it gets highlighted by the IDE, and I have too many other "gray" comments that would not get read unless someone is looking at those sections specifically, so another regular comment would be easily overlooked. The suggestion for external tools or files is even worse: Pretty much nobody will check them when it's time for refactoring. It has to be inline. Sure, it can't become too much, but one such "triggerable TODO" comment for just a few modules is fine.
When I write the code I can often already see options to make it more scalable or generalizable, but as it is currently being use the additional cost is not worth it, and if there never is future expansion the code actually is fine as it is. When I already know what needs to be done because my brain is fully 'inside' this code it would be a waste to throw that knowledge away, and regain all the contextual knowledge and ideas with a lot of work a year later. Those are the cases when I add such comments. They are not necessarily "TODO" level at that point, I use that tag only when additional conditions are met and I'm sure I want to avoid missing the comment.
Occasionally, when I have some time over, I scan through my TODOs, there are about 2/1000 LoC. Most of them I leave alone because the condition for their realization has not been met yet, but sometimes I find one of them is worth doing at that point. If it was a general comment I would have no chance to find them that easily. If they were in an external tool or file they would deviate from the actual code more and more, since we do quite a bit of refactoring due to growth and changing needs. But if there's a highlighted TODO in a module you are refactoring it's impossible to miss, so it is easy to update or remove those if they become invalid, even more so than regular "gray" comments.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#183When I see just a simple `TODO` in some OSS project it's often hard to understand either it's a broken edge case or some micro optimization or refactoring left for future. For my projects I adopted (it grew naturally) priority tags, e.g. `TODO!!! [(WTF)]` for critical [tricky/edge case] bugs, `TODO!` for important hot paths optimizations, `TODO (low)` for nice to have, `TODO?` or `TODO (review)` for rethinking design…
That's a great idea, I'm going to give it a go myself, thanks!
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#184Link not working for me. I’m getting this:
Error: Network error: Origin https://todos.tickgit.com is not allowed by Access-Control-Allow-Origin.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#185TODO is vital for my development process. Sure, maybe there's better programmers who don't use or need TODO, but for me, it's a critical method for the following reasons. 1. It prevents my "flow" from being sidetracked by micro-optimizations that are probably too early to consider necessary anyway. 2. It helps me to retain my short term memory on the code I am working on. If I branched out at each TODO to implement s…
At work we made it a policy to allow TODOs to remain until code review. At least there, with the help of a second pair of eyes, they should be resolved, removed or made into an issue.
Until now this approach works quite well for us.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#186In 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 can see a TODO from 1999 that could be fixed now. There couldn't have been a plan to fix it back then.
I don't run Linux myself, I'm not going to bother looking through some bug tracking system.
If someone had deleted the TODO then I think I would be less likely to contact the original author.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#187TODO is the prerogative of lazy programmers, who wants others to fix their bugs.
Or, a way of staying focused on the highest priority work at any given point in time.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#188I'm curious to learn how this is with other large codebases, or operating systems at Apple and Microsoft. I imagine the amount of open bugs or todo's will be much larger, many also from decades ago with no chance of ever being touched.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#189I think Students could use them as homework/assignment
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#190TODO is vital for my development process. Sure, maybe there's better programmers who don't use or need TODO, but for me, it's a critical method for the following reasons. 1. It prevents my "flow" from being sidetracked by micro-optimizations that are probably too early to consider necessary anyway. 2. It helps me to retain my short term memory on the code I am working on. If I branched out at each TODO to implement s…
#1 is also great for agile projects where you know things can be made better but there are no resources in the current sprint.
It also help colleagues to discover why you didn't implement things optimally. So they know you were not lazy but responsible.