Thought about programing: TODO or not TODO?
In this post I share my thoughts about a common phenomenon I noticed in many projects and according to the way I'm looking at the problem it is fundamentally wrong.
I'm talking about the comments in application code that start with the prefix: //TODO
I found these weird comments starting with //TODO prefix followed by all kinds of excuses why things have been left in an unfinished state, with the promise of a brighter future, making a surprise for the next person working with the same piece of code. These TODOs are usually quite old and many times if you ask the original authors about them, not only that they don’t have a proper plan to resolve them, but they even forget what they were about.
Because I have an “almost” photographic memory, here is a concrete example I reconstructed from my memories:
领英推荐
Yeah.. well, almost exactly the way it was :)
No surprise that in many times these conversations end like this:??“I don’t remember.... but it’s quite old and it’s just working so you can delete it, if you want”
In one of my old projects I found so many TODOs that at some point I started to believe that the main purpose of the project was to be a host for these parasites, and I was pretty sure they will survive the end of the project, hanging around on the main git branch holding the skeleton of the dead project.
But jokes aside, in my opinion, if you are using any tooling for project planning, more advanced than an excel sheet, you already have a place to describe current and future development. So these TODOs which are referring to future development, should be described there, in the form of a User Story/PBI/Task. This way, the work they are referring to, will most probably have a closure, you will roll them in your backlog to next iterations, up until they get implemented or removed, because you are tired of reprioritizing them.
If you are a fan of “clean coding principles”, you can easily realize that these comments are contributing to a bad signal to noise ratio in your code anyway!
Senior Fullstack Entwickler (Java und Angular), Language Engineer
3 年We solved this problem by turning code TODOs into Github Issues automatically. Then the Issue is assigned to someone and they have to solve it. When the TODO is removed from the code, the Github Issue is also closed automatically. ??
Software Architect | Certified Azure Solutions Architect Expert
3 年Totally agree with NOT TODOs or at least with TODOs that contain the task number. Nice article ??