Thought about programing: TODO or not TODO?

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:

No alt text provided for this image

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!

Mihai Andronache

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

Cristian Cazan

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 ??

回复

要查看或添加评论,请登录

Tibi Nagy的更多文章

  • Why Certifications Still Matter

    Why Certifications Still Matter

    I’m thrilled to share that I’ve just earned the Microsoft AI-102: Designing and Implementing an Azure AI Solution…

  • Unit tests simplified: how to bring order in chaos

    Unit tests simplified: how to bring order in chaos

    Despite the title of this article which is too dramatic, because probably there is no chaos in the way most of us are…

  • Microservices simplified: Exception handling

    Microservices simplified: Exception handling

    In this article I'd like to discuss how exception handling can be implemented at application level without the need of…

  • Microservices simplified: Logging

    Microservices simplified: Logging

    In this article I'd like to discuss how logging can be implemented in a generic way without polluting the domain logic…

  • Microservices simplified: Configuration management

    Microservices simplified: Configuration management

    In this article I'd like to discuss how accessing application level configuration can be simplified using a convention…

  • Microservices simplified: Caching

    Microservices simplified: Caching

    In this article I'd like to discuss how caching can be simplified by abstraction in a way in which it extends the…

  • Microservices simplified: Inter service communication

    Microservices simplified: Inter service communication

    In this article I'd like to discuss how service-to-service communication can be simplified by abstracting the…

  • Microservices simplified: Distributed processes

    Microservices simplified: Distributed processes

    In this article I'd like to discuss from a birds eye view, how business processes, distributed across multiple…

  • Microservices simplified: An overview

    Microservices simplified: An overview

    In this series of articles I'd like to share ways in which microservice based solutions can be simplified and built in…

社区洞察

其他会员也浏览了