100 lines
No EOL
5.2 KiB
JSON
100 lines
No EOL
5.2 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "6255f21a-1a68-4b69-9bce-2272c065efd8"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-04-21T01:22:00+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": "Version-controlled commented-out code\n"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2022-11-20T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-04-21T01:22:00+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2022\/11\/20\/version-controlled-commented-out-code",
|
|
"langcode": null
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>Today, whilst debugging some legacy code within an application, I found several blocks of commented-out code.<\/p>\n\n<p>Some were previous debugging code which had been commented out, and some were old components or previous implementations - but instead of being removed when they were no longer needed, they remained in the codebase as commented-out lines - inactive but adding noise and complexity around the code that I was trying to understand and debug.<\/p>\n\n<p>To make it easier for me to figure out this code, I'd like it to be as clean to read and as simple to understand as possible.<\/p>\n\n<p>The codebase is version-controlled, so why would there be a need to comment out and keep the lines?<\/p>\n\n<p>Version control systems have a log of each change, so if you need to see previous changes, you can view the log and see what changed, when, and by who.<\/p>\n\n<p>You can also see any other files that were changed in the same commit, and usually, there will be a reference to the issue or ticket that required that change.<\/p>\n\n<p>If you need to re-add a change that had been removed, you can either do this manually or by reverting the commit.<\/p>\n\n<p>Should there be commented-out code within a codebase if it's version controlled? I'd say no unless there's a good reason for it to be there and it's providing some additional context or for a specific purpose. If it's an outdated implementation, some old debugging code, or a component that's no longer needed, I think that it should be removed, and people can use version control tools to find or re-introduce those changes if needed.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>Today, whilst debugging some legacy code within an application, I found several blocks of commented-out code.<\/p>\n\n<p>Some were previous debugging code which had been commented out, and some were old components or previous implementations - but instead of being removed when they were no longer needed, they remained in the codebase as commented-out lines - inactive but adding noise and complexity around the code that I was trying to understand and debug.<\/p>\n\n<p>To make it easier for me to figure out this code, I'd like it to be as clean to read and as simple to understand as possible.<\/p>\n\n<p>The codebase is version-controlled, so why would there be a need to comment out and keep the lines?<\/p>\n\n<p>Version control systems have a log of each change, so if you need to see previous changes, you can view the log and see what changed, when, and by who.<\/p>\n\n<p>You can also see any other files that were changed in the same commit, and usually, there will be a reference to the issue or ticket that required that change.<\/p>\n\n<p>If you need to re-add a change that had been removed, you can either do this manually or by reverting the commit.<\/p>\n\n<p>Should there be commented-out code within a codebase if it's version controlled? I'd say no unless there's a good reason for it to be there and it's providing some additional context or for a specific purpose. If it's an outdated implementation, some old debugging code, or a component that's no longer needed, I think that it should be removed, and people can use version control tools to find or re-introduce those changes if needed.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "2025-04-21T01:22:00+00:00",
|
|
"guid": null,
|
|
"hash": "14f3a718b42c7abd68a912676fde8f73",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |