Name validation best practices

Question

I have a form and I was wondering about best practices when validating names (specifically throwing out characters which do not typically make up a name e.g. 123%^*$£ though theoretically could) and if it's sensible to carry out anything more than checking for presence. I've often read that you shouldn't try validating a name but it got me wondering because surely there's a lot of data we can throw out.

For context a consultant involved in the same project as me has asked if we can validate against silly data appearing in any of the name fields in a form, that is first name, middle names and last name. I think it's relevant to state that I am a UK based developer as I'm sure naming laws will weigh into this question.

An example of an issue we had was that a user accidentally entered the date of birth in a name field - e.g. 16/06/1987. This was technically a valid name on our system but when this data reached an external API it crashed it. This was a mistake and I think it could have prevented with more strict validation.

I found the UK deed poll guidelines which impose restrictions on changing your name or title: http://www.deedpoll.org.uk/AreThereAnyRestrictionsOnNames.html

These specify that punctuation without phonetic significance are not allowed as well (among other things). However note that these are only guidelines - I'm not sure that the actual legal limitations of a British name are.

Would it be sensible to perform name validation based on these guidelines? Have you ever heard of anyone implementing something like this?

Answer 1

In general it is problematic to try to impose restrictions like this, not just for names but for many types of data. The robustness principle is really the best way to go, in my experience: "Be conservative in what you send, be liberal in what you accept."

I once was filing my taxes through a commonly used US tax application and my employer for part of that year had been sold to a company based in Canada (where postal codes contain letters and numbers.) When I went to enter the postal code, I was informed that the postal code I was trying to enter was invalid because it must only contain numbers. Then it pestered me repeatedly that the postal code was missing. It was really obnoxious and unnecessary.

In your situation, if you have issues with certain types data, you should probably have a exception process after the input has been captured and inform a human to evaluate the situation. Even then, if you happen to get unlucky enough to get someone actually named '2016/09/08' then you are SOL.

Answer 2

No, it's not sensible to try to implement these restrictions. There's many flaws, lots of which are enumerated in Falsehoods programmers believe about names

For example;

People’s names are written in ASCII. People’s names are written in any single character set. People have last names, family names, or anything else which is shared by folks recognized as their relatives.

An example of an issue we had was that a user accidentally entered the date of birth in a name field - e.g. 16/06/1987. This was technically a valid name on our system but when this data reached an external API it crashed it. This was a mistake and I think it could have prevented with more strict validation.

This is not the fault of the user but a fault with your error handling on the api call. Your api client should be tolerant of error responses from the API. If the third-party api you are calling crashed, that's a bug that they should resolve. Open a ticket with them reporting the crash. If they are unwilling to fix it, then that specific location in code is an appropriate place to validate inputs - but not to determine what's a valid name, merely to prevent api calls which can only fail.

All that said, you could provide as-you-type guidance to users, for example suggesting next to that entry "The name you've entered looks like a date, is this correct?". This is a much better user experience than getting back an error. I've seen this happen with validation before; my name is hyphenated, and when signing up for a service online, the form returned an error when I submitted it saying Your name is invalid. A better user experience would have been to have a warning on the page suggesting Names in our system cannot contain hyphens; instead enter a space. Best yet would be to not have the arbitrary restriction in place.

However note that these are only guidelines - I'm not sure that the actual legal limitations of a British name are.

It doesn't matter what the British guidelines are, or those of any other country. Even if you decide that this software will never be used outside Britain, what about British people from other countries? They won't necessarily fit into the guidelines.

validate against silly data appearing in any of the name fields in a form, that is first name, middle names and last name

Not all people have middle names. Not all people have last names. Not all people have one last name or one middle name.

---

Generally speaking, try to make as few assumptions as possible and construct your data storage around how it needs to be used. Don't use names as unique identifiers, instead have a username or user id. Store a single "name" value rather than splitting into first/middle/last. If you're interfacing with an external system that requires you to do things like that, store and present the data in the minimal way that still lets you do it.