91 lines
No EOL
4.1 KiB
JSON
91 lines
No EOL
4.1 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "82672338-b561-408d-a17e-902c1f37e6a9"
|
|
}
|
|
],
|
|
"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:22+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": "Please don't use short variable names"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2024-01-17T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-05-11T09:00:22+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2024\/01\/17\/short-variable-names",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>When learning to code, one of the most confusing things was using short variable names in documentation and other people's code.<\/p>\n\n<p>Things like <code>$k<\/code> and <code>$v<\/code> instead of <code>$key<\/code> and <code>$value<\/code> within loops, <code>$i<\/code> instead of <code>$index<\/code>, or <code>$e<\/code> when working with Exceptions.<\/p>\n\n<p>I've also seen slightly better names, such as <code>$idx<\/code> for index or <code>$ctx<\/code> for context.<\/p>\n\n<p>But what does this achieve?<\/p>\n\n<p>Why not write the full variable name and clarify what it refers to?<\/p>\n\n<p>It would be easier to read and understand for anyone reading the code, including Junior Developers and people new to your team or application.<\/p>\n\n<p>There are no limitations - at least in the languages I use - to force this, such as a maximum number of characters in a file, so why not write the full variable name?<\/p>\n\n<p>The only reason I can think of is to save time by pressing fewer keys, but code is read more than written, so it should be optimised for readability.<\/p>\n\n<p>Your tests and CI pipeline don't have a preference.<\/p>\n\n<p>The people reading the code will.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>When learning to code, one of the most confusing things was using short variable names in documentation and other people's code.<\/p>\n\n<p>Things like <code>$k<\/code> and <code>$v<\/code> instead of <code>$key<\/code> and <code>$value<\/code> within loops, <code>$i<\/code> instead of <code>$index<\/code>, or <code>$e<\/code> when working with Exceptions.<\/p>\n\n<p>I've also seen slightly better names, such as <code>$idx<\/code> for index or <code>$ctx<\/code> for context.<\/p>\n\n<p>But what does this achieve?<\/p>\n\n<p>Why not write the full variable name and clarify what it refers to?<\/p>\n\n<p>It would be easier to read and understand for anyone reading the code, including Junior Developers and people new to your team or application.<\/p>\n\n<p>There are no limitations - at least in the languages I use - to force this, such as a maximum number of characters in a file, so why not write the full variable name?<\/p>\n\n<p>The only reason I can think of is to save time by pressing fewer keys, but code is read more than written, so it should be optimised for readability.<\/p>\n\n<p>Your tests and CI pipeline don't have a preference.<\/p>\n\n<p>The people reading the code will.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
]
|
|
} |