TODO: Refactor this

Anyone who’s worked on a sufficiently large code base will have probably come across a comment like this one.

// TODO: Refactor this

No doubt left there by some well-meaning developer and probably ignored by everybody else since.

Sometimes it will be accompanied by a rant about exactly what’s wrong with the code in question.

Comments like this serve no useful purpose!

They may serve as a bit of a stress-relief for the person inspired to write it but other than that are a waste of time. If the person leaving it wasn’t inclined to do the refactoring then what makes them think someone else will?

Or maybe they optimistically think they can come back when they get some free time and do it. They almost never will find that free time – the comment will sit there until the developers on the team no longer even notice it anymore.

Here’s what I like to do when I come across some code that I think could do with some refactoring…

Consider working on it right away

If I have time and/or it’s in scope I’ll try to refactor it there and then.

If I can’t do it right away…

Raise a tech debt ticket in the bug tracking software

This creates an actionable task that can be discussed by the team and tracked.

Leave a TODO comment referencing the bug tracker number

This ties the code in question back to the ticket.

Add my name/initials to the comment

This gives people someone to talk to if they happen across the comment.

Oh yeah, and I save the rants for down the pub!

2 thoughts on “TODO: Refactor this”

  1. I had exactly that on a project a while back – the tech lead saw fit to comment some code, critiquing it, even going so far as to describe how it should be refactored.

    Well, go on then! You think it should be done, you have the power to make it happen; (make someone) do it, or raise a bug in Jira, don’t be all passive-aggressive about it.

  2. Personally I find them rather helpful while spiking a solution, or going through the code trying to change something else. Oftentimes something catches your eye, you think you should take a look later or deal wth some edgecase, but right now you are on another mission. Unfortunately IDE’s don’t seem to currently have a nice way to comment a section of code without modifiying it (currently working in C#, the best VS can do is bookmark). TODO’s are poor mans solution. Now, these should be dealt with but doing this via raising yet another ticket is not always the best solution. You just encourage becoming a slave to the system. This naturally only works if you actually deal with the TODOS’s. Once you have your feature implemented, or your spike working, but before checking in, going through the code looking for quality and edegcase issues these TODOs can be very helpful. Unfortunately sometime you have to commit now so other devs can start playing with your feature. In this case you deal with the TODOs after commit. They definitely shouldn’t stay in the code.

Leave a Reply

Your email address will not be published. Required fields are marked *