4 ms·

At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code r

At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code review.

jrochkind1 5y ago
If it's got an accompanying JIRA ticket, what do you experience as the value of also including the `TODO` in a source comment, over just the jira ticket alone? [edit: reasonable answers below, thanks!]
- yakubin 5y ago
  When reading the source code, you immediately see an acknowledgement of the deficiencies, instead of assuming that everything is as it should be, or needing to investigate what is ok and what is not. It also maintains a link between the ticket and the location in source code throughout future source code changes.
- gbear605 5y ago
  Suppose a future developer is working on a separate ticket that touches the same code. If there’s an inline TODO, the future developer knows that the TODO needs something changed, which can help them understand how the code works and they might wind up resolving that TODO as part of the second ticket. If there isn’t an inline TODO, the issue might be resolved without that first ticket ever being touched. I see it inevitably leading to a lot of dead meaningless tickets crowding up the backlog. If an even later developer then was assigned one of those unknowingly-resolved tickets, they might spend a significant amount of time looking through the codebase to find where the code needs to be fixed, only to realize later that they’re looking for nothing.
- Izkata 5y ago
  From the opposite direction as the other responses, I've recently been running across years-old weirdness that involves digging through commits and merges to find the original Jira issue to explain it, then add a comment and reference to it to the code. They're not TODOs, they're explanations for future devs about why something was done on an odd way, so explicitly distinguishing a TODO would be better for those cases.

At work we use "TODO(JIRA-XXXX):", where JIRA-XXXX is the Jira ticket for the TODO. Every TODO needs an accompanying Jira ticket. Otherwise it won't pass code review.

jrochkind1 5y ago

If it's got an accompanying JIRA ticket, what do you experience as the value of also including the `TODO` in a source comment, over just the jira ticket alone? [edit: reasonable answers below, thanks!]

yakubin 5y ago
When reading the source code, you immediately see an acknowledgement of the deficiencies, instead of assuming that everything is as it should be, or needing to investigate what is ok and what is not. It also maintains a link between the ticket and the location in source code throughout future source code changes.
gbear605 5y ago
Suppose a future developer is working on a separate ticket that touches the same code. If there’s an inline TODO, the future developer knows that the TODO needs something changed, which can help them understand how the code works and they might wind up resolving that TODO as part of the second ticket. If there isn’t an inline TODO, the issue might be resolved without that first ticket ever being touched. I see it inevitably leading to a lot of dead meaningless tickets crowding up the backlog. If an even later developer then was assigned one of those unknowingly-resolved tickets, they might spend a significant amount of time looking through the codebase to find where the code needs to be fixed, only to realize later that they’re looking for nothing.
Izkata 5y ago
From the opposite direction as the other responses, I've recently been running across years-old weirdness that involves digging through commits and merges to find the original Jira issue to explain it, then add a comment and reference to it to the code. They're not TODOs, they're explanations for future devs about why something was done on an odd way, so explicitly distinguishing a TODO would be better for those cases.