{ "uuid": [ { "value": "a4098387-c0b8-43c4-8010-5cf12c8fae28" } ], "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:21:48+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": "Verbosity over abstraction\n" } ], "created": [ { "value": "2023-09-06T00:00:00+00:00" } ], "changed": [ { "value": "2025-04-21T01:21:48+00:00" } ], "promote": [ { "value": false } ], "sticky": [ { "value": false } ], "default_langcode": [ { "value": true } ], "revision_translation_affected": [ { "value": true } ], "path": [ { "alias": "\/daily\/2023\/09\/06\/verbosity-over-abstraction", "langcode": null } ], "body": [ { "value": "\n

Recently, a steamer said they \"prefer verbosity over abstraction\/confusion\".<\/p>\n\n

In that scenario, it was regarding the name of a microservice they were creating. It was long and verbose, but it described what it did.<\/p>\n\n

It was clear to anyone working on that project what that service did, now and in the future.<\/p>\n\n

I prefer this to shorter, less-descriptive names.<\/p>\n\n

I hardly ever create a variable called $x<\/code>, $k<\/code> or $v<\/code>. I only would if it was clear what it meant within its context.<\/p>\n\n

I like to write descriptive names for test methods that explain what the test is doing. Even if I start with a vague name, I'll refactor it to make it more specific and clearer.<\/p>\n\n

I prefer not to use PHP functions like compact<\/code> and to write it out and avoid the abstraction and any confusion it could cause.<\/p>\n\n

I prefer code to be verbose, descriptive and easy to read, understand and change.<\/p>\n\n ", "format": "full_html", "processed": "\n

Recently, a steamer said they \"prefer verbosity over abstraction\/confusion\".<\/p>\n\n

In that scenario, it was regarding the name of a microservice they were creating. It was long and verbose, but it described what it did.<\/p>\n\n

It was clear to anyone working on that project what that service did, now and in the future.<\/p>\n\n

I prefer this to shorter, less-descriptive names.<\/p>\n\n

I hardly ever create a variable called $x<\/code>, $k<\/code> or $v<\/code>. I only would if it was clear what it meant within its context.<\/p>\n\n

I like to write descriptive names for test methods that explain what the test is doing. Even if I start with a vague name, I'll refactor it to make it more specific and clearer.<\/p>\n\n

I prefer not to use PHP functions like compact<\/code> and to write it out and avoid the abstraction and any confusion it could cause.<\/p>\n\n

I prefer code to be verbose, descriptive and easy to read, understand and change.<\/p>\n\n ", "summary": null } ], "feeds_item": [ { "imported": "2025-04-21T01:21:48+00:00", "guid": null, "hash": "9d832e6a96400a2022d179422d39c66a", "target_type": "feeds_feed", "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76" } ] }