6 ms·

For the database at least, I don't see why you need unit tests or any testing at all. Assuming that you're going to require at least two names (no single-name

For the database at least, I don't see why you need unit tests or any testing at all. Assuming that you're going to require at least two names (no single-name names allowed), then a string for First Name and a string for Last Name should be sufficient. If this is a decent database, where the string can have any Unicode character, including a space, and you don't set a limit on the string length (modern databases don't need this), then how can there possibly be a problem? If your database can't handle arbitrary-length Unicode strings, you have much, much bigger problems than weird people names. (And if you want to handle single-name names too, you can either just have a single "name" field, or you can allow null values for the first name.) Now, the application logic is another matter and probably should be tested. But this really shouldn't be a hard problem, and it's downright shameful that so many programmers have bungled this so badly. There really isn't that much to it: you need to have two strings (and one can be null as I said above), they need to support Unicode so you can handle accented characters or characters from non-Latin character sets (Japanese, Chinese, Cyrillic, etc.), you need to handle spaces in names, and you need to not have arbitrary length restrictions (this could be a problem in web forms, but even here you should be able to make it scroll inside the box). The only valid limitation I can see is not allowing names with backslashes (in PostgreSQL, nulls are represented in SQL dumps with "\N").

kbenson 11y ago
Perhaps you should read, or if you have read, really internalize the "Falsehoods Programmers Believe About Names" link referenced above. Here's some choice excerpts: 5. People have exactly N names, for any value of N. 11. People’s names are all mapped in Unicode code points. 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name. 20. People have last names, family names, or anything else which is shared by folks recognized as their relatives. 32. People’s names are assigned at birth. 33. OK, maybe not at birth, but at least pretty close to birth. 34. Alright, alright, within a year or so of birth. 35. Five years? 36. You’re kidding me, right? 40. People have names. What this really means is, depending on the application and how important the name is to you, you will have different requirements. You need to fit your schema to your needs. For some applications, the name may be important, and extra care might need be taken to reflect the user's entry as accurately as possible. For others, it may simply be a string you expect your payment processor to accept, and that's all you care about.
- Grishnakh 11y ago
  I already addressed many of these by just advising to have arbitary-length strings (and maybe just a single one). That takes care of #5, #11, and #20. I don't see how #32 - 36 are even relevant: your system should just take whatever name they give you. How long they've had the name is irrelevant (as long as you have a mechanism to change it). #40: Sorry, but how can you not have a name? Good luck getting an ID document without a name. That doesn't make sense. #11: This just sounds dumb: Unicode has thousands upon thousands of characters. Only with Chinese can I see this possibly being a problem, but even here I thought Unicode did account for that. Unicode was designed to have every conceivable glyph that every language on Earth uses.
  - kbenson 11y ago
    > Sorry, but how can you not have a name? Good luck getting an ID document without a name. That doesn't make sense. That's what 32-36 are referring to, cases where children aren't given a name for an extended period of time. Even without extreme cases. what about a Hospital system meant to be used to track newborn children? It's necessarily not going to be able to rely on a name, because it's not uncommon for children not to be named for a few days. A system such as that might want to track the children by the mother, date of birth, and birth ordering (in case of twins, triplets, etc). > This just sounds dumb: Unicode has thousands upon thousands of characters. Only with Chinese can I see this possibly being a problem, but even here I thought Unicode did account for that. Unicode was designed to have every conceivable glyph that every language on Earth uses. Just because it was designed to accommodate every conceivable symbol, doesn't mean it currently has every conceivable symbol. What about the symbol Prince used for his name[1]? What about a language that's not in Unicode yet? > There really isn't that much to it: you need to have two strings (and one can be null as I said above) If someone has a single name, does it go in the first name, or second name spot? Is this enforced, and where? It's not that you won't generally be served well by your suggestions, it's just that the problem space is complex enough that it's worth thinking about a little before falling back on that. It might be that you don't even need a name, or only need it for billing, and your requirements may change depending on what payment processors expect (is it okay to just save a single string for whatever full name they submit?) These are all worth giving a little thought to up front, because changing the schema after it's in use is always harder, and that goes both ways, Splitting a string into multiple name parts is hard for many of the same reasons listed here. 1: http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode/ http://parkerhiggins.net/2013/01/writing-the-prince-symbol-i...
Dr_tldr 11y ago
Your comment is a perfect example of the kind of incomplete and normative reasoning about names that causes systems to fail. The problem isn't that you're not careful, the problem is that your fundamental assumptions are based on incomplete knowledge. For instance, you mentioned accommodating Cyrillic letters, but you didn't know you'd need to include a field for patronym, which is not the same thing as a middle name and can't just be included in the first name field without causing potential problems.
- alextgordon 11y ago
  And there's at least tens of millions of people who only have one name: https://en.wikipedia.org/wiki/Mononymous_person#Modern_times https://en.wikipedia.org/wiki/Mononymous_person#Modern_times https://en.wikipedia.org/wiki/Indonesian_names#Mononymic_names https://en.wikipedia.org/wiki/Indonesian_names#Mononymic_nam...
- Grishnakh 11y ago
  No, I addressed this. It's really simple: you don't need fields for different names!! Just have a single field: "name". That's it. People can put whatever name they want there, using any character set. If they want a "patronym", whatever the hell that is, no problem, just stick it in there! If they want a suffix like a bunch of Southerners here in America insist on for some archaic reason (like "Jimmy Bob Dalton III" or "Joe Smith Jr."), no problem, just put it there. For mailing addresses, this is all you need. Postal organizations do NOT care about your name, they just want your address and some kind of name as a check in case there's a delivery problem (or there's been a forwarding address filed for a particular name). Payment processors may need something more defined, but those are frequently more standardized by country, but usually, at least here in the US, all they care about is "enter your name as it's written on the card here...". They don't care about your actual name, they just want to match the string you enter with the string the credit card has.
hibbelig 11y ago
Say you have first name "John" and last name "Doe", then the software will print "John Doe" or "Doe, John" or "Mr. Doe". For Ai Weiwei, "Weiwei Ai" doesn't make sense, "Ai, Weiwei" is odd, and it has to be "Mr. Ai".
- dgacmu 11y ago
  And if we're being picky, name: 艾未未, and oops, there goes my other idea that I can at least use the spaces between words to figure out what's going on... ;)
gnaritas 11y ago
> Assuming that you're going to require at least two names (no single-name names allowed), then a string for First Name and a string for Last Name should be sufficient. Not even close; you're already off the rails with assumptions that break for tons of names. There's an easy way to do names decently, ask the user for their full name all in one field, and ask them for a nickname for use with the app and email and such. If you try to break their name down into parts, you're doing it wrong; names are not normally structured data, they're just unstructured free text.

kbenson 11y ago

Perhaps you should read, or if you have read, really internalize the "Falsehoods Programmers Believe About Names" link referenced above. Here's some choice excerpts: 5. People have exactly N names, for any value of N. 11. People’s names are all mapped in Unicode code points. 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name. 20. People have last names, family names, or anything else which is shared by folks recognized as their relatives. 32. People’s names are assigned at birth. 33. OK, maybe not at birth, but at least pretty close to birth. 34. Alright, alright, within a year or so of birth. 35. Five years? 36. You’re kidding me, right? 40. People have names. What this really means is, depending on the application and how important the name is to you, you will have different requirements. You need to fit your schema to your needs. For some applications, the name may be important, and extra care might need be taken to reflect the user's entry as accurately as possible. For others, it may simply be a string you expect your payment processor to accept, and that's all you care about.

Grishnakh 11y ago
I already addressed many of these by just advising to have arbitary-length strings (and maybe just a single one). That takes care of #5, #11, and #20. I don't see how #32 - 36 are even relevant: your system should just take whatever name they give you. How long they've had the name is irrelevant (as long as you have a mechanism to change it). #40: Sorry, but how can you not have a name? Good luck getting an ID document without a name. That doesn't make sense. #11: This just sounds dumb: Unicode has thousands upon thousands of characters. Only with Chinese can I see this possibly being a problem, but even here I thought Unicode did account for that. Unicode was designed to have every conceivable glyph that every language on Earth uses.
- kbenson 11y ago
  > Sorry, but how can you not have a name? Good luck getting an ID document without a name. That doesn't make sense. That's what 32-36 are referring to, cases where children aren't given a name for an extended period of time. Even without extreme cases. what about a Hospital system meant to be used to track newborn children? It's necessarily not going to be able to rely on a name, because it's not uncommon for children not to be named for a few days. A system such as that might want to track the children by the mother, date of birth, and birth ordering (in case of twins, triplets, etc). > This just sounds dumb: Unicode has thousands upon thousands of characters. Only with Chinese can I see this possibly being a problem, but even here I thought Unicode did account for that. Unicode was designed to have every conceivable glyph that every language on Earth uses. Just because it was designed to accommodate every conceivable symbol, doesn't mean it currently has every conceivable symbol. What about the symbol Prince used for his name[1]? What about a language that's not in Unicode yet? > There really isn't that much to it: you need to have two strings (and one can be null as I said above) If someone has a single name, does it go in the first name, or second name spot? Is this enforced, and where? It's not that you won't generally be served well by your suggestions, it's just that the problem space is complex enough that it's worth thinking about a little before falling back on that. It might be that you don't even need a name, or only need it for billing, and your requirements may change depending on what payment processors expect (is it okay to just save a single string for whatever full name they submit?) These are all worth giving a little thought to up front, because changing the schema after it's in use is always harder, and that goes both ways, Splitting a string into multiple name parts is hard for many of the same reasons listed here. 1: http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode/ http://parkerhiggins.net/2013/01/writing-the-prince-symbol-i...

Dr_tldr 11y ago

Your comment is a perfect example of the kind of incomplete and normative reasoning about names that causes systems to fail. The problem isn't that you're not careful, the problem is that your fundamental assumptions are based on incomplete knowledge. For instance, you mentioned accommodating Cyrillic letters, but you didn't know you'd need to include a field for patronym, which is not the same thing as a middle name and can't just be included in the first name field without causing potential problems.

alextgordon 11y ago
And there's at least tens of millions of people who only have one name: https://en.wikipedia.org/wiki/Mononymous_person#Modern_times https://en.wikipedia.org/wiki/Mononymous_person#Modern_times https://en.wikipedia.org/wiki/Indonesian_names#Mononymic_names https://en.wikipedia.org/wiki/Indonesian_names#Mononymic_nam...
Grishnakh 11y ago
No, I addressed this. It's really simple: you don't need fields for different names!! Just have a single field: "name". That's it. People can put whatever name they want there, using any character set. If they want a "patronym", whatever the hell that is, no problem, just stick it in there! If they want a suffix like a bunch of Southerners here in America insist on for some archaic reason (like "Jimmy Bob Dalton III" or "Joe Smith Jr."), no problem, just put it there. For mailing addresses, this is all you need. Postal organizations do NOT care about your name, they just want your address and some kind of name as a check in case there's a delivery problem (or there's been a forwarding address filed for a particular name). Payment processors may need something more defined, but those are frequently more standardized by country, but usually, at least here in the US, all they care about is "enter your name as it's written on the card here...". They don't care about your actual name, they just want to match the string you enter with the string the credit card has.

hibbelig 11y ago

Say you have first name "John" and last name "Doe", then the software will print "John Doe" or "Doe, John" or "Mr. Doe". For Ai Weiwei, "Weiwei Ai" doesn't make sense, "Ai, Weiwei" is odd, and it has to be "Mr. Ai".

dgacmu 11y ago
And if we're being picky, name: 艾未未, and oops, there goes my other idea that I can at least use the spaces between words to figure out what's going on... ;)

gnaritas 11y ago

> Assuming that you're going to require at least two names (no single-name names allowed), then a string for First Name and a string for Last Name should be sufficient. Not even close; you're already off the rails with assumptions that break for tons of names. There's an easy way to do names decently, ask the user for their full name all in one field, and ask them for a nickname for use with the app and email and such. If you try to break their name down into parts, you're doing it wrong; names are not normally structured data, they're just unstructured free text.