{ "uuid": [ { "value": "0b2c61c6-d125-44fc-8dd4-d5657f48af12" } ], "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:02+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": "Coding defensively, and Implicit vs explicit coding" } ], "created": [ { "value": "2022-10-09T00:00:00+00:00" } ], "changed": [ { "value": "2025-04-21T01:22:02+00:00" } ], "promote": [ { "value": false } ], "sticky": [ { "value": false } ], "default_langcode": [ { "value": true } ], "revision_translation_affected": [ { "value": true } ], "path": [ { "alias": "\/daily\/2022\/10\/09\/coding-defensively-implicit-explicit", "langcode": null } ], "body": [ { "value": "\n

As well as being introduced to Astro<\/a> in Simon's most recent Pro Tailwind workshop, something else that we discussed was implicit vs explicit coding, and coding defensively.<\/p>\n\n

For example, if you had this code:<\/p>\n\n

const sizeClasses = {\n  small: 'px-3 py-1 text-sm',\n  medium: 'px-5 py-2',\n  large: 'px-7 py-2.5 text-lg',\n}\n\nconst shapeClasses = {\n  square: '',\n  rounded: 'rounded',\n  pill: 'rounded-full',\n}\n<\/code><\/pre>\n\n
Both the medium<\/code> size and square<\/code> shape have an implicit value.<\/p>\n\n
The small<\/code> size has a text size class of text-sm<\/code> and the large<\/code> size has text-lg<\/code>. As there isn't a text size added for medium<\/code>, it is implicitly text-base<\/code> - the default text size.<\/p>\n\n
Likewise, the rounded<\/code> shape has a class of rounded<\/code> and the pill<\/code> shape has rounded-full<\/code>. As a square button doesn't have any rounding, it has an empty string but it is implicitly rounded-none<\/code> - the default border radius value.<\/p>\n\n
If we were to code this explicitly, text-base<\/code> and rounded-none<\/code> would be added to their respective size and shape classes.<\/p>\n\n
It's mostly personal preference, but explicitly adding the additional classes could potentially future-proof the components if there was a situation where the text size or border radius was being overridden.<\/p>\n\n
It also makes it more obvious to anyone reading the code that these values are being set, rather than them needing to make that assumption - assuming that they're aware of the default values at all.<\/p>\n\n
It's similar to having this example PHP code:<\/p>\n\n
function __invoke(string $type, int $limit): void {};\n<\/code><\/pre>\n\n
Whilst I'm using type hints for the parameters to ensure that the values are a string and an integer respectively, it's also safe to assume that the type shouldn't be an empty string, so do we check for that?<\/p>\n\n
I'd also suggest that the limit shouldn't be a negative integer, so we'd want to check that the value is not less than zero, or if zero isn't being used as an \"all\" value, then we'd want to check that the limit is greater than one.<\/p>\n\n
In this case, the type hints add some explicitness to the parameters, but checking for these additional conditions adds another defensive layer to the code - forcing it to return earlier with an explicit error message rather than causing a vaguer error and elsewhere in the application.<\/p>\n\n
Personally, I like to be explicit and code defensively, making sure that I try and cover as many edge cases as possible and writing test cases for them.<\/p>\n\n
Coming back to the Tailwind example, the majority of us decided to add in extra classes after the exercise and it was an interesting discussion and part of the workshop.<\/p>\n\n        ",
            "format": "full_html",
            "processed": "\n          
As well as being introduced to Astro<\/a> in Simon's most recent Pro Tailwind workshop, something else that we discussed was implicit vs explicit coding, and coding defensively.<\/p>\n\n
For example, if you had this code:<\/p>\n\n
const sizeClasses = {\n  small: 'px-3 py-1 text-sm',\n  medium: 'px-5 py-2',\n  large: 'px-7 py-2.5 text-lg',\n}\n\nconst shapeClasses = {\n  square: '',\n  rounded: 'rounded',\n  pill: 'rounded-full',\n}\n<\/code><\/pre>\n\n
Both the medium<\/code> size and square<\/code> shape have an implicit value.<\/p>\n\n
The small<\/code> size has a text size class of text-sm<\/code> and the large<\/code> size has text-lg<\/code>. As there isn't a text size added for medium<\/code>, it is implicitly text-base<\/code> - the default text size.<\/p>\n\n
Likewise, the rounded<\/code> shape has a class of rounded<\/code> and the pill<\/code> shape has rounded-full<\/code>. As a square button doesn't have any rounding, it has an empty string but it is implicitly rounded-none<\/code> - the default border radius value.<\/p>\n\n
If we were to code this explicitly, text-base<\/code> and rounded-none<\/code> would be added to their respective size and shape classes.<\/p>\n\n
It's mostly personal preference, but explicitly adding the additional classes could potentially future-proof the components if there was a situation where the text size or border radius was being overridden.<\/p>\n\n
It also makes it more obvious to anyone reading the code that these values are being set, rather than them needing to make that assumption - assuming that they're aware of the default values at all.<\/p>\n\n
It's similar to having this example PHP code:<\/p>\n\n
function __invoke(string $type, int $limit): void {};\n<\/code><\/pre>\n\n
Whilst I'm using type hints for the parameters to ensure that the values are a string and an integer respectively, it's also safe to assume that the type shouldn't be an empty string, so do we check for that?<\/p>\n\n
I'd also suggest that the limit shouldn't be a negative integer, so we'd want to check that the value is not less than zero, or if zero isn't being used as an \"all\" value, then we'd want to check that the limit is greater than one.<\/p>\n\n
In this case, the type hints add some explicitness to the parameters, but checking for these additional conditions adds another defensive layer to the code - forcing it to return earlier with an explicit error message rather than causing a vaguer error and elsewhere in the application.<\/p>\n\n
Personally, I like to be explicit and code defensively, making sure that I try and cover as many edge cases as possible and writing test cases for them.<\/p>\n\n
Coming back to the Tailwind example, the majority of us decided to add in extra classes after the exercise and it was an interesting discussion and part of the workshop.<\/p>\n\n        ",
            "summary": null
        }
    ],
    "feeds_item": [
        {
            "imported": "2025-04-21T01:22:02+00:00",
            "guid": null,
            "hash": "2396dbcb354eade3105e541370b34bef",
            "target_type": "feeds_feed",
            "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
        }
    ]
}