Hacker News Reader

Comment by gnuvince | Hacker News Reader

Now that we have the standard "Haha, you don't know shit about names, and your program sucks!" pitch, where's the library/framework that developers can use that will take care of ALL these name issues? As a developer, I just want to record a person in my system, I don't want to learn about all the different cultures, character sets, name orderings, etc. that exist in this world. So, Patrick of Kalzumeus Software and other HN commenters who are disgusted that names can be truncated and whatnot, show us your respect for the culture of all Earth people and release a project that will accept any name (or no name, #40) for anyone ever without a single fault.

Until then, can we agree that getting things right for 99.999% of people in your target market is good enough, and that, although unfortunate for people with culturally different names, the time and cost of getting all 40 points right would be too damn high?

View on HN

My suggestions for dealing with names are:

1) Names are context-sensitive, so ask for a person's name by giving the context you intend to use it in. Something like, "How should we address you in an email?" or "How should we display your name to other people on the site?".

2) Do not apply any sort of transformation to a name. Don't parse it, don't truncate it, don't lowercase it. Treat it like an opaque string and use it verbatim.

3) Databases do need limits on the length of a column (unless you use a blob...) so be generous with the width of the columns. The longest recorded name is 746 letters long (http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior), so make sure it's longer than that.

4) I think the no-name case (#40) and the not-in-unicode case (#14) are fairly obscure, but if you want to handle them then then make names optional but require an avatar if they do not provide one.

5) Allow a person to change their name at any time.

There is one kind of normalisation that I think would be useful though, that is to normalise whitespace. That is trim leading and trailing whitespace, convert all whitespace to space and remove multiple spaces. Otherwise, as someone with a non-trivial surname, I agree. Facebook has always driven me insane in this regard.

I don't know if it's still the case, but Facebook used to have this annoying bug where they'd not only capitalise the first letter of my surname (incorrect!), they would then not allow for me to correct it because it seemed to have been treated case insensitively. They don't seem to enforce the capitalisation now since I've created a new account though. I know it was just a bug, but it was so disrespectful somehow.

The answer is to allow a single unicode text column for names, and don't try to validate it.

That's not very hard, and is in fact easier than trying to validate or restrict names. You don't have to learn about all the different cultures etc, just don't assume they are like yours.

What if their name uses non-unicode characters?

And 2048-character limit on that field ought to be enough for everyone, right?

Are there significant symbologies not contained within unicode?

Maybe Jimmy Page will change his legal name to Zoso? http://en.wikipedia.org/wiki/Jimmy_page#Interest_in_the_occu...

But that's exactly the issue here; there aren't many people with names as long as Janice's, but when these people have problems with computer systems, we get to hear about it.

What is a "non-unicode character"?

Why do you need a fixed character limit at all?

I don't know about your first question, but the reason you need a character limit is because each time a row is added to a database, enough space is set aside to contain that row.

Each row contains the same columns. For example: table Person: col1 label: name / type: text / size: 10 2 label: age / type: int / size: 3 3 label: address / type: text / size: 200

the type tells the database how to encode the data found in that column - an int takes less space than a string, so this is a space saving measure. The size refers to how many characters are allowed in that field, because that is how much space will be allocated when the row is created. If you don't need 200 characters of space, it's wasteful to allow it. But you kind of have to put a number in there, even if it's a big one.

Correct me if I'm wrong, all my knowledge comes from Dr. Marla Weston's 2nd year Databases Design course.

Not all databases store varchar differently from a text column, for example I don't think PSQL distinguishes between the two in storage and there are no performances improvements from using varchar.

http://www.postgresql.org/docs/9.3/interactive/datatype-char...

A very poor course indeed if it told you to use fixed-size data types for arbitrary string data, or implied all string types in databases were fixed-size. SQL string types like VARCHAR and TEXT are assuredly variable, using only the storage necessary to hold the actual data (plus bookkeeping overhead). CHAR is fixed-size, but I can't remember the last table I created with a CHAR column. They're quite uncommon in comparison.

> What is a "non-unicode character"?

A character with no representation in the latest Unicode standard.

> What if their name uses non-unicode characters?

Learn to fix the problems you can fix, and only the problems you can fix. Ignore the problems you cannot fix because, as per hypothesis, you cannot do anything about them.

In other words, what if you get hit by a micrometeorite on your way to the bathroom tomorrow?

Even that will fail at least point #11, and possibly point #39.

I'm not sure there's anything we can do about point #11 - do do you have a suggestion without fixing unicode? Like a few of the last points it's not possible to satisfy every possible problem, but using unicode without restrictions at least gets you most of the way there, it's better than other encodings if you need worldwide support though it has recognised issues with more complex character sets.

Then what if someone starts putting in unicode control characters? What if you display their name as the title of a window and they made their name start with two right to left control marks, causing Windows to invert the entire window contents?

For specific uses (like output to html), you will have to escape the content, as with any other content, but you can store what the user input.

names are no different from any other form of user input in this regard. Any time you include user input in a document you should follow it with a direction override character to restore the text direction, just in case the user changed it. You could also strip these characters out, but some people really do want their name to show up backwards, and for that to be consistent across all cases.

What if you need to call out to a third party API like a payment system which requires a first name and a surname? If you've not collected those things, you're screwed.

Billing names are a separate problem from user names. If you're collecting for payment, obviously you have to conform to whatever your API requires, but often it's better to keep billing details separately.

Sorting is another area where it'll vary a lot depending on locale (perhaps you want to sort on last name for example, or not depending on your users) - it might be best to try to guess that from whatever they enter, rather than imposing a structure on them.

Personally I'd choose the simplest solution which works, so no last name/first name, just a name field for display, depending on the requirements, a website/app might need to collect more of course, but for most websites there's no reason to try to control user names or split them up into arbitrary first/last pairs.

Apparently you should use an infinite-length Unicode-compatible textarea with no validation whatsoever. I think the point is that it's wrong to think you can validate names.

Reply on news.ycombinator.com