Have you ever noticed outdated // TODO: comments in your codebase that should have been addressed ages ago? 🤔
Well, how about this then:
// Th...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
This looks great!
Unfortunately, sometimes it's project planning/time constraints that prevent us from finishing off a to-do. For example, I've been in situations where I've been rushing to get something done for the end of a sprint. I put in a note to say that some code has been hacked together and that it should be done properly. However, I wasn't given time in the subsequent sprints to address the issue as other things had higher priority.
That sucks, man! I feel you, been there too. It's okay to reschedule though.
On the flip side, I've seen many cases in the past, when we were delaying some stuff because we were waiting for a 3rd party library to update, etc, etc.
Or, when we have to upgrade a piece in our code at some point, because of some deprecation happening in the future that we already aware of.
Just some cases when an expiring TODO helps to keep stuff organized and under control, but there are def more of them.
I can see that an expiring TODO would definitely help. The fact that an expiry date keeps popping up would probably make me bring it up repeatedly during sprint planning. Even if not, it'd act as a reminder for the little bits of downtime between sprints.
Simply don’t do “TODO” in your code if there is no real, real, big, good reason for it!
In most cases, you will never do the “todo”, as long as it works.
You will find your todos years later in the code base, no one will have an idea what exactly needs to be done.
If “you hack” something, only to reach a sprint goal - you probably do something wrong. Because the ticket is not done in this case, if you need to work on it again 😜.
It’s only hiding “did not complete the task” from others.
Keep you code clean and implement stuff properly once, instead of mess up code with lot of future maintenance.
If there are parts where you have follow ups. Then you can add a Todo comment with a ticket number (jira/GitHub issue…) to your code and throw something like “not implemented”.
The ticket should exactly describe what needs to be done.
This way it can be picked up by someone else and added to plannings and sprints properly.
This way the ToDo is only a simple back-reference in your code to find the right code lines and to signal to everyone “aware of it, planned…”
That'd be the ideal state of the codebase!
Unfortunately, in reality, oftentimes, you see codebase in between such "ideal" states, and that's where TODOs are helpful.
Ultimately though, I'd even say that comments is a an anti-pattern: it's easy to write code that is self-documentary already.
But overall, that's a really good overview, thanks, Sebastian! Makes total sense.
by changing the TODO expiry date
🤣