Hacker News Reader

Comment by jpswade | Hacker News Reader

Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done.

They never get prioritised and very rarely does anyone get to do them.

So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.

View on HN

> It feels like a todo is really only there to serve as an excuse for suboptimal solutions.

That's not the only way to use a TODO, but even if it was, it's still valuable to mark suboptimal code.

Imagine you're investigating a performance bug and see a comment in related code which says "TODO: use a faster sorting method", that's probably going to be helpful.

Delivering something is far more preferable to never delivering a perfect solution, most of the time. TODO is a way of dealing with guilt about imperfection while actually shipping.

I dunno... I think they have their place.

I'm working on a personal project right now and in order to see how things look, if they work etc, I've got a bunch of vanilla js frontend code and //TODO in a few places to call an API and get actual data. It works great for now as I've hardcoded everything, got it looking broadly like the finished product, and it means that I just have to do the API calls (and programme the API too, of course).

I use them a lot.

On a personal project, I can see this working, on a team project, you're not gaining anything with TODOs, because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero.

Not only are you rarely gonna have the time to fix the TODO, but weeks, months, years later when you run into a TODO in your code, you have no idea what the actual requirements were, why it was not implemented, why it hasn't hurt anyone and whether anyone is actually needing it. Thus the TODO comment will remain forever, as you can't figure out what to do about it, without investing a lot of time and energy on requirement engineering.

Personally, I've started to block PRs with TODO comments that aren't directly mentioning the future implementation story/bug. As such, even if the TODO is forgotten in some way, you at least will find a reference point to what should have been done here.

> because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero.

This depends entirely on the team, company and/or work, though. It certainly is not a given.

> TODO in your code, you have no idea what the actual requirements were, why it was not implemented, why it hasn't hurt anyone and whether anyone is actually needing it

This depends on the task you are TODO-ing. Sure, if it is a "TODO: seems broken, fix." or "TODO: make sure that users don't see this", you are putting not just the wrong things in TODOs you are not giving them enough context. Compare that with a "TODO: this duplicates the routine in FooBars#bar_bar, but we cannot move this to a generic helper until the BarBar can handle both ActiveUsers and PendingUsers. Once that polymorphism is implemented, this can be DRYd up", which gives context, predicaments, and communicates that the author knows it is suboptimal, and explains how the author would've fixed it.

It certainly all "depends". My main point is, that if you don't actively plan in to fix your TODOs, then they usually won't be fixed, which you can also kind of see in a lot of the charts where the amount of TODOs just goes up. And as such the question arises whether you really gain anything from them.

I much rather have someone finalize their implementation and create follow up stories/tasks to indicate what needs to be done next, than having hints of what should've/could've been done and nobody ever going back and cleaning those up.

Here's my most common use case:

1) Need to do a hotfix on some bug. Fastest fix is to just turn off something.

2) I turn it off (maybe commenting out the line) then add a TODO above it with the ticket number that corresponds to the ticket for turning it back on once the issue has been investigated.

3) Once I start working on the ticket to turn the thing back on, having the todos makes it easy to know exactly what to do (context isn't lost) and I don't end up missing some things because I can just search all of the TODOs.

4) If a TODO is missed, we have a script that will re-open any ticket for which a TODO ticket number is still in the codebase. i.e, let's say we have "TODO: xy-123 ..." If i close xy-123 without deleting that line, the script will re-open the ticket and comment saying that there is a remaining todo

> they often don’t give any indication how they are going to get to done

It would be a really bad practice to merge procedures and policy with technical artifacts. TODOs embedded in the code are technical artifacts, they say what should change, they really shouldn't say how and when.

> They never get prioritised and very rarely does anyone get to do them

Well, you are faulting the tool for your development practices. If your team doesn't look at TODOs, you indeed should avoid them. But that doesn't mean anything for other people.

At my workplace embedded TODOs would be bad too. At personal projects I find them quite useful with a similar life-cycle to warnings: you keep them there while the feature is being developed, but they must be gone by the time it's complete. Other people have different practices, and may successfully use them in different ways.

I'd rather have a todo (that marks the line with a nice bright color in my IDE) than the immediate alternatives of #1: Not implementing a feature because it has room for improvement, or #2: Leave out the deficiency marking because it makes the code look more complete.

Reply on news.ycombinator.com