Best Practices for Name Validation

validation

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?

Best Answer

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.

Related Solutions

Data validation best practices: how can I better construct user feedback

Should I be describing what the user did correctly or incorrectly, or simply what was expected?

If you don't describe the "incorrectly" and "what was expected", the user is lost and cannot make a change. What they did correctly is obvious, since it's not invalid.

What they did incorrectly tells them what to change.

What's expected should tell them what kind of change to make.

How much detail can the user read before they get annoyed?

Varies from user to user. There's no general answer. And there's no easy way to know. Experienced users want short messages. N00bz need long messages. And you can't know the user's level of expertise until after they complain about the messages.

How do I decide between phrases like "must not," "may not," or "cannot"?

You can't decide. It's not your choice. It's your users. In American English (which doesn't even use "shall" except in legal documents) the differences are minor and vary by user. Each user has a personal level of discomfort (or comfort). You can't know the user's level of comfort until after they complain about the messages.

Generally, folks don't like computers telling them way they "must" do. Other than that, it's individual preferences.

This can depend on the project, but how should the information be delivered to the user?

Um... This makes no sense. If the data's invalid, you can't go forward.

Should it be obtrusive (e.g. JavaScript alerts) or friendly?

This makes no sense. "obtrusive" and "friendly" aren't orthogonal.

Should they be displayed prominently? Immediately (i.e. without confirmation steps, etc.)?

This makes no sense. If the data's invalid, then they can't go on, so it has to be prominent.

Do you bother logging validation errors?

Talk to your lawyers about the consequences of users making entry errors. In the medical field, it might matter. In other fields, it rarely matters. If you're fine-tuning your presentation, you'll want to log things so you can figure out what the most common error is and re-engineer things so it cannot possibly be made. If your users are all n00bz (because the app never existed before) you'll need to log things so you can work out the real use cases. If your users are all experts, don't bother logging.

How do I cater to the majority of users?

You can't. Preferences for support and guidance vary by individual person, their level of expertise and their overall comfort with computers and the application. Broad cultural generalizations are less important than individual ones.

C# Best Practices – Constructor Parameter Validation

I tend to perform all of my validation in the constructor. This is a must because I almost always create immutable objects. For your specific case I think this is acceptable.

if (string.IsNullOrEmpty(text))
    throw new ArgumentException("message", nameof(text));

If you are using .NET 4 you can do this. Of course this depends on whether you consider a string that contains only white space to be invalid.

if (string.IsNullOrWhiteSpace(text))
    throw new ArgumentException("message", nameof(text));

Best Answer

Related Solutions

Data validation best practices: how can I better construct user feedback

C# Best Practices – Constructor Parameter Validation

Related Topic