oliverdavies.uk/content/node.781bcd5b-be77-4514-bffc-aa56d829aaff.yml

78 lines
4 KiB
YAML
Raw Normal View History

2025-07-10 00:14:12 +01:00
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: |
<p><a href="/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>
<p>But what about TODO comments that remind you to do something?</p>
<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>
<p>I recently removed a small number from a codebase I added while working on the first MVP.</p>
<p>They were comments like "Move this to a repository" or "Remove this hard-coded value and make this configurable".</p>
<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>
<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>
<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>
format: full_html
processed: |
2025-07-16 12:00:00 +01:00
<p><a href="/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>
2025-07-10 00:14:12 +01:00
<p>But what about TODO comments that remind you to do something?</p>
<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>
<p>I recently removed a small number from a codebase I added while working on the first MVP.</p>
<p>They were comments like "Move this to a repository" or "Remove this hard-coded value and make this configurable".</p>
<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>
<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>
<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>
summary: null
field_daily_email_cta: { }