Day 2 - Nuke TODO comments

Congrats on making it to day 2!

Today’s exercise is short and sweet: grep your codebase for TODO comments.

When you find one, I recommend you do one of the following:

  1. Is it out of date? Delete it.
  2. Is it still relevant? Delete it and add it to whatever system you use to track work to be done, like GitHub Issues or Trello or Asana.
  3. Are you unsure? Do a little research and/or track down the comment’s author and get an answer. Then do 1 or 2 :).

Why do this? Because code is a lousy place to track todos. When a todo lives in your code, it can’t be prioritized or scheduled, and tends to get forgotten.

For extra points, submit a PR that deletes all the TODO comments and include links to the newly-created issue for each one. Should make for an easy review/approval.

Worth noting: spend 20 minutes on this task and then declare victory. Success is showing up and putting in the time, not necessarily deleting every comment. If you can only delete one comment in 20 minutes, you’ve still succeeded for the day (well done!)

Finally, when you’re done, please share how old the oldest TODO comment you found.

Get to it!

1 Like

I am not very good with TODO comments. I don’t write them in my own code. I did find a few TODO comments to create a Readme, so might switch back to the day 1 challenge!

The oldest: as old as the project basically…

We have >100 TODO comments, so I only managed to chip away at it.
Bonus: in multiple cases I could delete whole functions/files instead of the TODO comment :slight_smile:

3 Likes

For those using Ruby on Rails bin/rails notes will search your project for them.

Now to find some to remove…

2 Likes

The oldest: 2015 (about 2 years into the life of the project). Feels good to get a few of these todos deleted

Just finished this one! I spent about 30-35 minutes because I went down a rabbit hole. But I was able to remove a bunch of TODO comments, and I found a loop that was calling the database (huge code smell for me) so I refactored that as well.

The oldest one I found was from 2018. My project has a relatively young codebase (we started working on it in June of 2020) so the TODO itself was from our team project template, and was no longer applicable anyway.

Edited to add: moving the database calls out of the loop took that particular block of code from taking ~250ms per page load to ~50ms per page load in my tests. There are definitely scenarios where this will save a lot more time than that. Woo!

1 Like

Hopefully, this is something my team was aware of so we didn’t have so many. Yet, I’ve found ~15 to be cleaned up. Mostly old notes and “maybe someday we would do this”. It has been more than a year and we haven’t. I just got rid of the cruft!

The oldest, from 14 months ago:

// TODO: maybe remove this in the future in favor of importing it directly?

Spoiler: nope, we never had to.

I find that it captures the essence of these. Sounds familiar? :smile:

Didn’t find any in the codebase :woohoo:
Though having a “todo” component led to a few hundred false positives.

Removed two TODO comments today which is almost a 0.1% improvement. Had to check with two different teams for those on context. Oldest was from 2015.

I scrap todos pretty regularly so only had 7 and was able to delete 6 right away. The last had some helpful notes for a bug so I added those to the ticket instead of keeping them in the code.

The oldest was 4 months old (project is only 1 year old though)

Day 2 in the books! Was able to get rid of an unused rake task :confetti_ball:

Some food for thought for the forum on this task :slightly_smiling_face:

Depending on the content of the TODO comment, I think those can sometimes be okay hanging out in the codebase without a corresponding ticket. Sometimes the TODO comment could capture a limitation or quirk that entails a scope such that the corresponding ticket could hang out in a team’s backlog for quite some time and if this is the case, I think a comment is more valuable to me as a reader of the codebase than a stale ticket hanging out somewhere in the backlog. The comment is also a more upfront signpost alongside the relevant code as opposed to a ticket that wouldn’t be referenced in the codebase.

I think I would be okay if the comment existed, and just referenced the ticket. But no comment and just TODO ticket seems less helpful to me :hushed:

Curious to hear how others feel on this topic!

1 Like

I think I would be okay if the comment existed, and just referenced the ticket. But no comment and just TODO ticket seems less helpful to me :hushed:

That’s very interesting indeed. I think it depends on your codebase and team practices.

With time, I’ve noticed that:

  • A problem with tickets is that they are disconnected from the code. Devs won’t see the ticket from the code they are navigating, thus may miss the context
  • A problem with TODO comments is that they aren’t tracked explicitly, thus representing hidden work that easily gets lost

Also, it’s frequent that devs don’t have full control over the ticket backlog. Other people are involved, or responsible for it. These people may not realize that, just like TODO comments, it’s not helpful to keep hundreds of tickets “just in case”.

Back to the TODO comments: one solution that worked well for me in my previous gig was to make sure all TODO comments had the ticket ID mentioned. And to create tickets for TODO comments, so all the backlog work is explicit for everyone. No hidden work.

It also made it easier to:

  • add more context around the TODO in the ticket (eg. media, ongoing discussions…)
  • get rid of a TODO comment (if the related ticket was closed, then it’s not relevant anymore)

Nowadays I don’t need to keep the TODOs much since we have full ownership of the ticket backlog and a large knowledge of the codebase. But this changes depending on your reality IMO.

2 Likes

It’s only a small open-source project, but I got the TODOs down from 7 to 2.

The 5 I deleted were my remnants from a massive incremental refactor a few weeks ago, where I probably had a peak of 20 or 25 temporary TODOs, and I got them down a long way before running out of steam and time. I knew I had these last few to nuke.

All the time I was doing that refactoring I was conscious of a recent quote from someone on Twitter, which was something like:

Treat TODOs like items in the fridge/refrigerator… They are fine for a few days, but after that they really start to smell a lot and you should get rid of them.

Doing the search was hard, though, as the entire project is a task tracking plugin for Obsidian, so there are a lot of TODO strings in the code.

The project is about 2 years old - I took it over 6 or 8 months ago. The oldest TODO is from May 2022.

1 Like

I didn’t have TODOS in the code.
So I take this 20 minutes to just create tasks in gitlab repo and remove it from my head.
I think I should put more tasks but at least the most important ones are now in gitlab.

Deleted quite a few to-do’s that were outdated (already addressed or solved in a new update). Moved pending ones to my Todoist app for team member discussions, and the other ones to my Clear list app for diving into our lessons learned / knowledge base when I have free time. :cloud:

Oldest TODO from October 2nd, 2021.

Late to the party, but here’s mine: Update a `var` from `public` to `internal` in `MockStorageManager` by mokagio · Pull Request #8556 · woocommerce/woocommerce-ios · GitHub

I found 63 TODOs in 46 files. I couldn’t devise a way to find out which was the oldest, so I did a random sampling of a dozen of them. The oldest there was from April 2020.

No TODO comments. I already follow the rule. Either GitHub Issue or Trello card. In the past, my projects had more than 20 TODO comments where non of them gets done and they all stay there forever.