Hacker News new | past | comments | ask | show | jobs | submit login

You need to check both that its valid and that its still open. Many times I've seen TODOs with issues in code where the issue was closed. Since nothing gates the Issues being closed, you've now broken CI by closing them.

Say you do get past that hurdle, you've added friction to the process of managing the backlog because the code now needs to be updated when Issues are rejected.

The sad part? With almost 10 years on a 20-30 year old code base with many millions of lines of code that are littered with TODOs, I don't think the presence of a TODO was ever helpful when we decided to actually fix an issue.




> The sad part? With almost 10 years on a 20-30 year old code base with many millions of lines of code that are littered with TODOs, I don't think the presence of a TODO was ever helpful when we decided to actually fix an issue.

Makes perfect sense. TODOs are comment, meaning they're as reliable as comments, meaning they often aren't (and the more time passes and code churns around them the less they are).


Totally agree. I've found that adding a timeline to _remove_ TODOs/DREAMS (whatever the team choice is) from code as a CI check is very applicable -- what you thought might be good at some point in the past may (and likely is) not applicable later down the road!

Clean the code, comment actualities later, etc. -- it helps with knowledge share to find ways to make you attend to cleaning things up.


I've done this too (commenting with the ticket # - well, link to ticket), and it's worked quite well for me/us. It's fairly easy to follow the link & check on it, and it can also serve as a tombstone for why a particular issue isn't being addressed.


I've been tempted to put issues in the repo, which would solve this problem (and create others).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: