Is it controversial to say that those with low TODOs are pretty clearly the cleanest packages I enjoy working with most? (Postgres, Rust, Django, VueJS, maybe Python)
Plotting the source code “TODO” history of the most popular open source projects
61–70 of 114 posts
Re: Plotting the source code “TODO” history of the most popular open source projects
#62I wonder what other strings people use like this. So far I have seen FIXME TODO HACK XXX BROKEN.
At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code review.
If it's got an accompanying JIRA ticket, what do you experience as the value of also including the `TODO` in a source comment, over just the jira ticket alone?
[edit: reasonable answers below, thanks!]
Re: Plotting the source code “TODO” history of the most popular open source projects
#63I always suggest TODO's to be replaced during a Code Review by:
1. A ticket number that will be picked up shortly if should still be part of a larger change. In a healthy team, this is done within two weeks and you know where to perform changes when you pick it up.
2. You do not add a TODO, but explain your current understanding of what is wrong and what should be done. This way you can refresh the knowledge if it ever again is touched. With a simple TODO, this knowledge is usually not writtend down.
Re: Plotting the source code “TODO” history of the most popular open source projects
#64Just today I announced a sweep through all of the TODO's and to either turn them into issues, stories or remove them. Biggest problem in Xcode is that it clogs up the warning list and the real warnings get swamped by them. But it's funny to see that Rust has less outstanding TODO's than our brand new 45KLoC project.
TODOS are great documentation. They often reveal design decisions, suboptimal implementations and the thought process of the creator. This information is often completely lost in issues that noone will ever look at again. I also like to do TODO sweeps, but with a bias towards rewriting the into documentation or leaving them in if the are actionable.
Instead of TODO, I often add a NOTE instead now, e.g.:
NOTE: Attempting to re-synchronize here would cause an infinite loop because...
Re: Plotting the source code “TODO” history of the most popular open source projects
#65Earlier quoted context omitted.
At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code review.
If it's got an accompanying JIRA ticket, what do you experience as the value of also including the `TODO` in a source comment, over just the jira ticket alone? [edit: reasonable answers below, thanks!]
When reading the source code, you immediately see an acknowledgement of the deficiencies, instead of assuming that everything is as it should be, or needing to investigate what is ok and what is not. It also maintains a link between the ticket and the location in source code throughout future source code changes.
Re: Plotting the source code “TODO” history of the most popular open source projects
#66Earlier quoted context omitted.
At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code review.
If it's got an accompanying JIRA ticket, what do you experience as the value of also including the `TODO` in a source comment, over just the jira ticket alone? [edit: reasonable answers below, thanks!]
Suppose a future developer is working on a separate ticket that touches the same code. If there’s an inline TODO, the future developer knows that the TODO needs something changed, which can help them understand how the code works and they might wind up resolving that TODO as part of the second ticket. If there isn’t an inline TODO, the issue might be resolved without that first ticket ever being touched. I see it inevitably leading to a lot of dead meaningless tickets crowding up the backlog. If an even later developer then was assigned one of those unknowingly-resolved tickets, they might spend a significant amount of time looking through the codebase to find where the code needs to be fixed, only to realize later that they’re looking for nothing.
Re: Plotting the source code “TODO” history of the most popular open source projects
#67What about amount of TODOs per character or line of code?
Agreed, this could make the graphs much more comparable and maybe reflective of project culture. Comparing something like the linux kernel to VueJS is nonsensical without any normalization with respect to overall repo size.
Re: Plotting the source code “TODO” history of the most popular open source projects
#68Re: Plotting the source code “TODO” history of the most popular open source projects
#69It was interesting to see that Swift has 2K+. Seemed kinda high when I consider it's youth and uptake relative to some of its plotted peers.
I don't know wether to suspect that's because it has
a) an overly parliamentary development process that just creates lots of bookkeeping side affects
b) a very aspirational development community that is busy writing tons of "try to take over the world" goals to improve in various and sundry ways
c) indicates a lot of short sighted/highly focused language evolutions that leave a long trail of todos because that kind of "we have no big picture" creates a lot of corner/edge cases that need "todo" signs to document them
d) something else?
Re: Plotting the source code “TODO” history of the most popular open source projects
#70Interesting that some of them don't grow, or don't grow much, over time. Someone at PostgreSQL and Django is actually reading and fixing the TODOs.
While it's probably the case for postgres or Django, todos getting less could also mean high code churn.
Yeah I noticed several cases were there to do's drop dramatically. I wondered if that was because that was a module that had a lot of to-dos that was also low quality, and the subject of a complete rewrite or replacement at some point. Golang was also interesting because of a huge increase followed by an almost equally huge decrease a short time later, both of them seemingly vertical. I wonder if something got reverted, or if they actually went back and addressed a bunch of to-dos.