uuid: - value: 781bcd5b-be77-4514-bffc-aa56d829aaff langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:51+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: | What to do with TODO comments created: - value: '2022-12-03T00:00:00+00:00' changed: - value: '2025-05-11T09:00:51+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2022/12/03/what-to-do-with-todo-comments langcode: en body: - value: |
In a previous email, I wrote about commented-out code and whether it should remain in a codebase - especially if it's version controlled and there's a commit log of all changes.
But what about TODO comments that remind you to do something?
When I think of TODO comments, I think of times when I've found them left in codebases from a long time ago by Developers who no longer work on it - never to be looked at again.
I recently removed a small number from a codebase I added while working on the first MVP.
They were comments like "Move this to a repository" or "Remove this hard-coded value and make this configurable".
These weren't things that would affect the functionality of the code - but nice-to-haves, things that could be done differently, or reminders of things where hard-coded values were fine but would need to be replaced in the future.
Instead of being code comments that only I was aware of, I moved them into the issue-tracking system I'm using. This allows the client to have visibility of them and that they can be scheduled and prioritised alongside other work, providing a truer reflection of the current tasks.
Some have since been addressed, but some will remain and be actioned in the future. If they were still code comments, they might not have been addressed at all, so the issue tracker seems like the better place for them to be.
format: full_html processed: |In a previous email, I wrote about commented-out code and whether it should remain in a codebase - especially if it's version controlled and there's a commit log of all changes.
But what about TODO comments that remind you to do something?
When I think of TODO comments, I think of times when I've found them left in codebases from a long time ago by Developers who no longer work on it - never to be looked at again.
I recently removed a small number from a codebase I added while working on the first MVP.
They were comments like "Move this to a repository" or "Remove this hard-coded value and make this configurable".
These weren't things that would affect the functionality of the code - but nice-to-haves, things that could be done differently, or reminders of things where hard-coded values were fine but would need to be replaced in the future.
Instead of being code comments that only I was aware of, I moved them into the issue-tracking system I'm using. This allows the client to have visibility of them and that they can be scheduled and prioritised alongside other work, providing a truer reflection of the current tasks.
Some have since been addressed, but some will remain and be actioned in the future. If they were still code comments, they might not have been addressed at all, so the issue tracker seems like the better place for them to be.
summary: null field_daily_email_cta: { }