Live data from Hacker News

Plotting the source code “TODO” history of the most popular open source projects

schleiss.io

31–40 of 114 posts

Re: Plotting the source code “TODO” history of the most popular open source projects

#31
post #4

Interesting to see that most of them are almost always growing. It would be interesting to compare them to some other metrics, such as TODO/lines_of_code or TODO/num_contributors, to compare the TODO's with the size of the project. I guess that as project gets bigger, it also gets more TODO's

> TODO/lines_of_code

At least this is needed for any meaningful comparison between project (or even in projects themselves, as some double in SLOC count over a few months)

Re: Plotting the source code “TODO” history of the most popular open source projects

#32
post #31
post #4

Interesting to see that most of them are almost always growing. It would be interesting to compare them to some other metrics, such as TODO/lines_of_code or TODO/num_contributors, to compare the TODO's with the size of the project. I guess that as project gets bigger, it also gets more TODO's

> TODO/lines_of_code At least this is needed for any meaningful comparison between project (or even in projects themselves, as some double in SLOC count over a few months)

Ignoring the numbers on vertical axis, plots look like they are normalized to fit the plotting area. TODO/LoC should basically have the same form.

Re: Plotting the source code “TODO” history of the most popular open source projects

#33

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.

It would also be interesting to plot the number of TODOs against the size of the code base too. One would assume that as a project grows, the number of outstanding TODOs would grow too. Where and when this isn't true, might reveal something more interesting.

Re: Plotting the source code “TODO” history of the most popular open source projects

#37

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.

While it's probably the case for postgres or Django, todos getting less could also mean high code churn.

Re: Plotting the source code “TODO” history of the most popular open source projects

#39
post #31

Earlier quoted context omitted.

> TODO/lines_of_code At least this is needed for any meaningful comparison between project (or even in projects themselves, as some double in SLOC count over a few months)

Ignoring the numbers on vertical axis, plots look like they are normalized to fit the plotting area. TODO/LoC should basically have the same form.

I don't think so. These plots are normalized by the max number of TODO's, but that may vastly differ from max TODO/LoC of each project.

Re: Plotting the source code “TODO” history of the most popular open source projects

#40
post #26
post #18

Just 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.

Can't you configure Xcode to filter out such warnings? TODOs offer valuable insight but they may not warrant turning into issues or stories. Removing valuable information because it's cluttering seems like a shame. Better if you can filter it in such a way that it doesn't clutter

Quick idea: You could use a different wording that doesn't get recognized by Xcode but sticks out in a similar way. It would take some time to get used to it though.
Post reply on HN