4 ms·
I agree that code searchability is a good thing but I disagree with those examples. They intentionally increase the chance of errors. Maybe there’s an alternat
by amingilani 2y ago
I agree that code searchability is a good thing but I disagree with those examples. They intentionally increase the chance of errors.
Maybe there’s an alternative way to achieve what the author set out but increasing searchability at the cost of increasing brittleness isn’t it for me.
In this example:
const getTableName = (addressType: 'shipping' | 'billing') => {
return `${addressType}_addresses`
}
The input string and output are coupled. If you add string conditionals as the author did, you introduce the chance of a mismatch between the input and output.
const getTableName = (addressType: 'shipping' | 'billing') => {
if (addressType === 'shipping') {
return 'shipping_addresses'
}
if (addressType === 'billing') {
return 'billing_addresses'
}
throw new TypeError('addressType must be billing or shipping')
}
Similarly, flattening dictionaries for readability introduces the chance of a random typo making our lives hell. A single typo in the repetitions below will be awful.
{
"auth.login.title": "Login",
"auth.login.emailLabel": "Email",
"auth.login.passwordLabel": "Password",
"auth.register.title": "Login",
"auth.register.emailLabel": "Email",
"auth.register.passwordLabel": "Password",
}
Typos aren’t unlikely. In a codebase I work with, we have a perpetually open ticket about how ARTISTS is mistyped as ATRISTS in a similarly flat enum.
The issue can’t be solved easily because the enum is now copied across several codebases. But the ticket has a counter for the number of developers that independently discovered the bug and it’s in the mid two digits.
- Noumenon72 2y agoTypos are find-and-fix-once, while unsearchability is a maintenance burden forever. I don't think coupling variable names by making sure they contain the same strings is the best way to show they're related, compared to an actual map from address type to table name. There might be a lot of things called 'shipping' in my app, only some of which are coupled to `shipping_addresses`. Shouldn't a linter be able to catch that there is no enum member called MyEnum.ATRISTS, or is it not an actual enum?
- ctxc 2y agoAgree with you. What happens when translation files get too big and you want to split and send only relevant parts? Like send only auth keys when user is unauthenticated? `return translations[auth][login]` is no longer possible. Or just imagine you want to iterate through `auth` keys. _shudders_
- usrusr 2y agoEntrenched typos like ATRISTS are actually a greppability goldmine. Chances are there are more occurrences of pluralized people who are making art in the codebase, but only ATRISTS is the one from that enum. I certainly would not suggest deliberately mistyping, but there are places where the benefit is approaching the cost. Certain log messages can absolutely benefit from subtle letter garbling that retains readability while adding uniqueness.
- kaelwd 2y agoREFERER moment.
- peeters 2y ago> The input string and output are coupled. If you add string conditionals as the author did, you introduce the chance of a mismatch between the input and output. I think it depends on whether the repetition is accidental or intrinsic. Does the table name happen to contain the address type as a prefix, or does it intrinsically have to? Greppability aside, when things are incidentally related, it's often better to repeat yourself to not give the wrong impression that they're intrinsically related. Conversely, if they are intrinsically related (i.e. it's an invariant of the system that the table name starts with the address type as a prefix) then it's better for the code to align with that.