I'd be quite interested in seeing data on the age of TODOs over time - for instance, are there lots of old TODOs sitting around gathering dust while newer TODOs get fixed, or are they getting worked through?
Plotting the source code “TODO” history of the most popular open source projects
71–80 of 114 posts
Re: Plotting the source code “TODO” history of the most popular open source projects
#72Is 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)
Use and semantics of TODOs are decidedly not consistent across these projects.
Just because you (and I) see correlation with our expected biases shouldn't be construed as proof: merely interesting chart wiggles.
I think the shape (monotonic increase or sawtooth) can be used to see how a project handles either missing features of technical debt.
Re: Plotting the source code “TODO” history of the most popular open source projects
#73Just 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
I think it's actually my linter generating these warnings! But I do like them to be resolved so I consider them issues.
Re: Plotting the source code “TODO” history of the most popular open source projects
#74Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
> they often don’t give any indication how they are going to get to done
It would be a really bad practice to merge procedures and policy with technical artifacts. TODOs embedded in the code are technical artifacts, they say what should change, they really shouldn't say how and when.
> They never get prioritised and very rarely does anyone get to do them
Well, you are faulting the tool for your development practices. If your team doesn't look at TODOs, you indeed should avoid them. But that doesn't mean anything for other people.
At my workplace embedded TODOs would be bad too. At personal projects I find them quite useful with a similar life-cycle to warnings: you keep them there while the feature is being developed, but they must be gone by the time it's complete. Other people have different practices, and may successfully use them in different ways.
Re: Plotting the source code “TODO” history of the most popular open source projects
#75I 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.
Re: Plotting the source code “TODO” history of the most popular open source projects
#76Earlier quoted context omitted.
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... This prefix distinguishes such info from normal comments, which exclusively pertain to the code-as-written.
Agreed but that's not quite what's being discussed here.
Notes are great but the context is to make a note about something that can be improved in the future (something actionable), hence it being a TODO.
Re: Plotting the source code “TODO” history of the most popular open source projects
#77Damn, what happened to Typescript in May/June 2018? It jumped from around 730 TODOs to 3000, and has never really come back down.
Wikipedia's list of versions suggests that this was probably related to version 3 happening in July 2019.
Re: Plotting the source code “TODO” history of the most popular open source projects
#78Earlier quoted context omitted.
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
I think it's actually my linter generating these warnings! But I do like them to be resolved so I consider them issues.
everybody wants todos resolved but chances are that if a decision is made to fix, make issues or nuke them, they'll just get nuked instead
Re: Plotting the source code “TODO” history of the most popular open source projects
#79I wonder what other strings people use like this. So far I have seen FIXME TODO HACK XXX BROKEN.
With Vim, each filetype has its own set of rules for syntax highlighting (mostly contributed by third-party maintainers). A quick grep through the `/usr/share/vim/vim82/syntax` directory shows the most popular set of such strings that are to be syntax highlighted by Vim are:
TODO FIXME XXX
BUG NOTE CHECK DEPRECATED HACK TBD FIX TEMP REFACTOR REVIEW HACK Todo
Re: Plotting the source code “TODO” history of the most popular open source projects
#80Well, 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 honest, I have quite a few of those hanging out too.