I am requesting information about a Users address and as is good practice when collecting information, I validate the input and respond accordingly where appropriate.

Assuming valid input is received, the format of the input (particularly character casing) could be a bit funky.

For example; given the input 34b bAker STREET, I would ideally want this to be 34B Baker Street.

Now I could write logic for normalizing the input, however, given the multitude of address line formats (at least in the UK), is this an optimization that isn't really going to return much benefit as long as the input itself is valid?

Having funky casing is annoying, but not detrimental to the system functionality.

  • 2
    A simple (i.e. rule based) normalization may break more often than it helps. A smart one (e.g. Google maps API lookup) may work more often, but can still break. Maybe you could show suggestions to the user (using either way) but let them proceed with their input if they wish.
    – user44761
    Sep 21 '17 at 7:06
  • Does whoever downvoted wish to say why so that I know what I did wrong and can avoid doing so in the future? Was it too opinionated, not worded correctly? Sep 22 '17 at 6:43

The problem with normalizing data is that you cannot be sure that you're changing it for the better, even if most cases you probably are. Also I'm assuming if you were to check for the existence of said address already in the database, you'd perform a case-insensitive check, so letter casing is not particularly important in that regard.

The real problem comes from visualization of said data. Are you going to show the user the street address as he/she entered it or will you normalize it? That's somewhat subjective, but I figure you can always normalize it later if you need to, but only if you keep the data as is. If you normalize prior to inserting it in your database, you're forcing your hand in the matter and you'll never be able to show it as the user entered it.

In my experience, assumptions regarding names, addresses, and phone numbers cause trouble, and you cannot be faulted for simply showing the very same user that entered it in the first place the very same value. So in short, in the interests of flexibility and correctness, if it is valid, it is good enough to be added to your database as is.

  • I like this response and sums up my most recent thoughts on my question. Like you mentioned, I don't want to normalize data to a format I think is correct when the data was initially entered correctly anyway (34B LaBaker Street => 34B Labaker Street). Sep 21 '17 at 7:37

Normalizing an address is essentially impossible to do correctly with a rules-based algorithm. Fortunately, mail services want their senders to use accurate addresses, so many countries distribute databases of all the addresses they serve. In the UK it's called the Postcode Address File. There are various service providers who create nice APIs on top of the PAF to make address validation and normalization easy. You'll get out addresses in the form Royal Mail prefers you use, which is what you really want. This precisely matches the normalized address your customers will see from every website that does it properly.

  • Problems arise if there are multiple external services that have mutually incompatible preferred forms, or the user disagrees with what that service normalizes it to.
    – Caleth
    Sep 21 '17 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.