{
    "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\n"
        }
    ],
    "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": "\n          <p><a href=\"https:\/\/www.oliverdavies.uk\/daily\/2022\/11\/20\/version-controlled-commented-out-code\">In a previous email<\/a>, 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.<\/p>\n\n<p>But what about TODO comments that remind you to do something?<\/p>\n\n<p>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.<\/p>\n\n<p>I recently removed a small number from a codebase I added while working on the first MVP.<\/p>\n\n<p>They were comments like \"Move this to a repository\" or \"Remove this hard-coded value and make this configurable\".<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n        ",
            "format": "full_html",
            "processed": "\n          <p><a href=\"https:\/\/www.oliverdavies.uk\/daily\/2022\/11\/20\/version-controlled-commented-out-code\">In a previous email<\/a>, 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.<\/p>\n\n<p>But what about TODO comments that remind you to do something?<\/p>\n\n<p>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.<\/p>\n\n<p>I recently removed a small number from a codebase I added while working on the first MVP.<\/p>\n\n<p>They were comments like \"Move this to a repository\" or \"Remove this hard-coded value and make this configurable\".<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n        ",
            "summary": null
        }
    ],
    "feeds_item": [
        {
            "imported": "1970-01-01T00:33:45+00:00",
            "guid": null,
            "hash": "0cb985cce483116ecdf0ef9bbb61febe",
            "target_type": "feeds_feed",
            "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
        }
    ]
}