2 ms·

We have a lint rule that will fail if your TODO comment doesn't have a link to a ticket for that task in it. It's not perfect, but I think this has reduced TODO

We have a lint rule that will fail if your TODO comment doesn't have a link to a ticket for that task in it. It's not perfect, but I think this has reduced TODOs in our codebase to tasks that will be more or less done in the immediate future, e.g. follow-up PRs. Because of this, I think these TODOs are pretty helpful in code review. Reviewers often leave comments like, "while you're at it, why don't you do this too?". But with a TODO and a ticket, you can indicate that you're about to do that thing, but are breaking things up into smaller PRs to make things easier to review. Since there's a ticket associated with the TODO, it's a bit more likely to actually get done.

PretzelFisch 6y ago
I like that idea, I have always felt the TODO is something I add while working on a function/feature so I don't forget the edge case. I have never cared for a TODO representing a work item. Same with a code base littered with comments about fixing bug ###. With out the bug and source control diff how do I know what was part of the fix and when or how it has changed over time via other bug fixes and feature updates.
developer2 6y ago
I had heard of that idea before, and then forgot about it. Thank you for reminding me; I will be implementing that at work when I can find the time to add it to the pipeline (ie. "todo: enforce ticketed todos"). To me there are three variants of todo: 1. Personal and immediate todos. These MUST be resolved before I can even commit to VCS. This isn't a standard "todo"; rather, it marks a section of code which I've left incomplete while I jump around the code base to work on other things. I don't use "@todo" as the tag here; I use "@first-real-name" (eg. "@joe"), as JetBrains' IDEs let you define custom TODO tag names and then filter based on them. Thus, "@joe" has never made it into a commit to the VCS, as I always ensure these are resolved before I commit. 2. A true todo that is actionable, and has an extremely realistic (not idealistic) expectation that it must, or really-really-REALLY should, be worked on in the VERY near future. This is the kind of todo that would require a ticket. 3. Todos that are hypothetical, imaginative, or dreamy; ie; "I wish priorities allowed me to spend another $X days/weeks/months on this". Obviously, this is the entire reason why requiring tickets for todos is beneficial; these kind of todos need to be cut down and eliminated. It can be so hard to "give up" on something you know could be improved, but that realistically you'll never come back to on the company's dime. I'd also like to see alerts based on the datetime when a new todo was committed to the central repository. If a todo sits in code for more than 3 months, I want that alerted. Either the ticket needs to be prioritized, or the todo needs to be deleted.
talaketu 6y ago
We have a JIRA rule to close tickets if they are not likely to be worked on in the next 6 months.
- csharptwdec19 6y ago
  I'm torn on that, mostly because I worked at a shop where sometimes bugs weren't handled immediately because they were edge cases (but we had more serious ones in play). There was more than one time where a ticket from before I even started provided a critical clue, or at least a "We knew this was a problem and you didn't let us fix it" defense when the execs asked what happened. (Execs typically were the ones who forced us to add features instead of fix bugs)

PretzelFisch 6y ago

I like that idea, I have always felt the TODO is something I add while working on a function/feature so I don't forget the edge case. I have never cared for a TODO representing a work item. Same with a code base littered with comments about fixing bug ###. With out the bug and source control diff how do I know what was part of the fix and when or how it has changed over time via other bug fixes and feature updates.

developer2 6y ago

I had heard of that idea before, and then forgot about it. Thank you for reminding me; I will be implementing that at work when I can find the time to add it to the pipeline (ie. "todo: enforce ticketed todos"). To me there are three variants of todo: 1. Personal and immediate todos. These MUST be resolved before I can even commit to VCS. This isn't a standard "todo"; rather, it marks a section of code which I've left incomplete while I jump around the code base to work on other things. I don't use "@todo" as the tag here; I use "@first-real-name" (eg. "@joe"), as JetBrains' IDEs let you define custom TODO tag names and then filter based on them. Thus, "@joe" has never made it into a commit to the VCS, as I always ensure these are resolved before I commit. 2. A true todo that is actionable, and has an extremely realistic (not idealistic) expectation that it must, or really-really-REALLY should, be worked on in the VERY near future. This is the kind of todo that would require a ticket. 3. Todos that are hypothetical, imaginative, or dreamy; ie; "I wish priorities allowed me to spend another $X days/weeks/months on this". Obviously, this is the entire reason why requiring tickets for todos is beneficial; these kind of todos need to be cut down and eliminated. It can be so hard to "give up" on something you know could be improved, but that realistically you'll never come back to on the company's dime. I'd also like to see alerts based on the datetime when a new todo was committed to the central repository. If a todo sits in code for more than 3 months, I want that alerted. Either the ticket needs to be prioritized, or the todo needs to be deleted.

talaketu 6y ago

We have a JIRA rule to close tickets if they are not likely to be worked on in the next 6 months.

csharptwdec19 6y ago
I'm torn on that, mostly because I worked at a shop where sometimes bugs weren't handled immediately because they were edge cases (but we had more serious ones in play). There was more than one time where a ticket from before I even started provided a critical clue, or at least a "We knew this was a problem and you didn't let us fix it" defense when the execs asked what happened. (Execs typically were the ones who forced us to add features instead of fix bugs)