Very glad to see "Falsehoods Programmers Believe About Names" included in this list [1]. I still struggle to always get this right.
One thing I'd suggest including is something about not rolling your own crypto in the security section. Does anyone know a canonical article for this? I've got [2] bookmarked but not sure if a guide with the pitfalls of designing your own crypto scheme is right for this list.
I really like the FHIR Human Name data type[0]. It requires none of the fields... so it can represent someone without a name. It also has all the necessary fields for representing someone's name and their name in various forms and pretty much as many edge cases as possible.
The only problem is turning it into a UI that makes sense.
I was helping someone with an appointment reminders implementation. I was googling how to communicate with practice management systems, came upon HL7, and then FHIR.
I don't do anything "real" with FHIR at my company, I just borrow concepts because FHIR does a pretty good job at encapsulating the healthcare domain.
So if you take these to heart, even a tiny weekend project will take near infinite time to handle all of these cases.
It would require infinite space, every possible supported character set, a massive fuzzy-logic search engine, etc.
Humans handle complexity by avoiding it until it becomes a pressing need. The first pass at understanding is always an oversimplified model. Usually we make additional passes, hopefully with progressively more nuanced and educated models.
Knowing that your system will run into problems in the future is sometimes enough. Deferring problems until they are actually significant business impacts is a reasonable strategy.
This applies to "Falsehoods Programmers Believe About {Names, Addresses, Phone Numbers, etc}".
> even a tiny weekend project will take near infinite time to handle all of these cases.
A "tiny weekend project" assumes, by definition, a tiny userbase. The point is to assume nothing about a dataset, because even dozens of seemingly reasonable expectations about names are wrong.
The point of the article is not to tell you to immediately write perfect code, but to make you aware of your code's limitations.
> Very glad to see "Falsehoods Programmers Believe About Names" included in this list [1]. I still struggle to always get this right.
In the real world, you'll constantly have to interact with external or internal systems that are based on the "wrong" concept, so implementing it "right" makes your system really awkward to work with.
I really like the FHIR Human Name data type[0]. It requires none of the fields... so it can represent someone without a name. It also has all the necessary fields for representing someone's name and their name in various forms and pretty much as many edge cases as possible.
The only problem is turning it into a UI that makes sense.
[0]: https://www.hl7.org/fhir/datatypes.html#HumanName