This is the reason I’ve stopped putting TODO’s in my code. I’ve never seen it used in a productive way, it just accumulates cruft. I also ignore them when reading code. They might document the original developers thinking in some way, but generally that line of thinking is not that relevant anymore when I get there.
TODO’s are basically a secondary issue management system. An issue management system that has no owner. No-one is looking at it and no-one besides the developer who put it in finds the TODO important. And even that developer didn’t think it was a major issue, or he would have fixed it before shipping.
You can either:
is there a script somebody has I could use to run the same on a git repo?
I feel like just looking at the total number of TODOs in a huge code base like the Linux kernel doesn’t tell you much. What would be interesting is number of TODOs over total LOCs.
Maybe also use information from source control to look at how long TODOs persist in the code base.
Every single one of the graphs shows projects accruing more todos over time, which we could assume means they have been added and for one reason or another forgotten about. There can also be seen some patterns where todo’s are being used as placeholders for work in progress that then gets done and the todo’s subsequently removed.
I think the whole point of the page isn’t necessarily to show much more than “look, these projects all accrue todo’s over time, maybe that would be a good place to go looking for providing assistance.” There are multiple reasons for why todo’s remain un-done.
What I find iteresting is the sudden jump of TODOs in just a couple of days. Maybe they were integrating external code in tree? It’s pleasing though to see the number drop occasionally
I made the assumption that was due to a refactoring in progress, or some other maintenance being carried out and placeholders being committed, but integrating external code is also a good guess at what caused it.
I personally use todo’s as placeholders, I will write a todo, then open an issue with the body of the todo, update the todo to have the issue number in its copy and then commit with the issue number referenced. This results in the issue being linked to the commit making finding the relevant file and line/s trivial.
that makes sense if those TODOs were scrapped, say, from the main branch and at some point some a big chunk of work containing a bunch of todos was merged into it