Interesting 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.
I suspect that in postgres'case that is just because a TODO list was moved out of the code...
Plotting the source code “TODO” history of the most popular open source projects
81–90 of 114 posts
Re: Plotting the source code “TODO” history of the most popular open source projects
#82Earlier quoted context omitted.
Back when I used Eclipse there was another level called “FIXME”. Maybe it works in IntelliJ as well.
It does. At least it works in PyCharm, so most likely it works in all IntelliJ based IDEs.
Yes, it does. In fact, you can configure it to use whatever you want. (I have it also match BUG as another priority)
Re: Plotting the source code “TODO” history of the most popular open source projects
#83Well, I'm glad I'm not the only one who never gets around to my //TODO#s. One related tip for devs: I've started adding "You are here" as a placemark for where I'm working in the code. So for example, on friday, if I want to pick up quickly next monday, I add "//TODO: YOU ARE HERE Finish doing foo". Then on monday, I search for "You are here" and pick up where I left off easier. Saves me a few cycles, though if I'm h…
even better, don't leave it as a comment. Leave it uncommented, as a syntax error, so when you try and run your code on Monday morning you are reminded of it!
Re: Plotting the source code “TODO” history of the most popular open source projects
#84I 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 ev…
Or do both. Might as well add TODO: to make it stand out as a thing that can be improved while also making it greppable.
Might also be cool to automatically create these tickets (when commited to master?). Then you don't forget, and even if they end up not that detailed, you at least get a nice list of all of them.
Re: Plotting the source code “TODO” history of the most popular open source projects
#85Earlier quoted context omitted.
Or do both. Might as well add TODO: to make it stand out as a thing that can be improved while also making it greppable.
Might also be cool to automatically create these tickets (when commited to master?). Then you don't forget, and even if they end up not that detailed, you at least get a nice list of all of them.
TODO: Automatically create tickets based on TODO comments.
We'll get to it. Someday.
Re: Plotting the source code “TODO” history of the most popular open source projects
#86Is 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)
Well, is the converse true? Are the packages with high TODOs the dirtiest packages that you least enjoy working with?
Re: Plotting the source code “TODO” history of the most popular open source projects
#87I 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 ev…
I like this idea, but I would add that my preference for scenario 2 is to add HACK (or FIXME) along with the explanation instead. This way it is still searchable, but you make it a bit more clear that there is no obvious fix at the moment.
Re: Plotting the source code “TODO” history of the most popular open source projects
#88Earlier 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!]
From the opposite direction as the other responses, I've recently been running across years-old weirdness that involves digging through commits and merges to find the original Jira issue to explain it, then add a comment and reference to it to the code. They're not TODOs, they're explanations for future devs about why something was done on an odd way, so explicitly distinguishing a TODO would be better for those cases.
Re: Plotting the source code “TODO” history of the most popular open source projects
#89The growing number is hardly surprising, yet I don't know exactly what the implications are. There are a lot of different categories of TODOs, ranging from harmless ("it would be nice if this was improved at some point") to critical ("this is a really bad solution that needs to be fixed ASAP"). I wonder if these repos has official definitions of what a TODO entails.
I use a priority number after my tags: @todo2, @todo9, etc.
Re: Plotting the source code “TODO” history of the most popular open source projects
#90Earlier quoted context omitted.
Might also be cool to automatically create these tickets (when commited to master?). Then you don't forget, and even if they end up not that detailed, you at least get a nice list of all of them.
TODO: Automatically create tickets based on TODO comments. We'll get to it. Someday.
https://en.wiktionary.org/wiki/round_tuit
There used to be an ASCII art version occasionally slapped on Usenet posts: "here's a round tuit, you can go ahead."