3 ms·

Of course, they're falsehoods that everyone believes about addresses (except maybe for postal workers), but programmers are the only ones who have to actually t

Of course, they're falsehoods that everyone believes about addresses (except maybe for postal workers), but programmers are the only ones who have to actually think about them. It would be nice to come up with some sort of conclusion or recommendation. Should addresses just be used as one big blob of text, and never parsed at all? should there be individual per-country libraries for parsing them? should we just address everything by coordinates (which doesn't solve the houseboat problem)? How about a unique identifier for every person on the planet, plus a gps tracking system that guarantees big brother can deliver to you whenever, wherever? Now that the average piece of post is a prig package that needs signing for, rather than a small letter that can just go through the letterbox, I quite like the idea of centralised pigeon-hole buildings, that have existed in many towns as the only method of delivery, but are now being born everywhere thanks to amazon, etc. That's quite a different problem, though :-)

curryhoward 12y ago
I think the consensus is to go with the "big blob of text" approach. You mentioned that postal workers are the only people qualified to parse addresses—let them do it. The validation done on your end shouldn't be much more than asserting that addresses contains non-whitespace characters. I don't know how well this works in practice, but it's the most "correct" thing to do.
- DanBC 12y ago
  I can understand not validating fields, but users are hopeless and like guidance. Giving them some structure in address fields helps the user through the system.
- misterS 12y ago
  > I don't know how well this works in practice, As soon as you don't control the whole thing end-to-end, i.e. from the user entering the data to printing it on an envelope: it won't work at all. It would require every program in the whole chain to accept this "big blob", which is simply not going to happen.
- walshemj 12y ago
  Bad mistake you get a metric fuck ton of shit in your data that way. You should always police your input data properly one big text field is lazy programming that leads to a big technical debt later on. And yes that does mean handling apostrophes and all those other edge cases properly.
  - to3m 12y ago
    Name of recipient, state/province/etc., postal code and country, maybe. But for the rest, that bit (at least in the UK) that goes in the middle... what policing can you do? That part is just a text blob. You can't do much meaningful with it except for showing it to somebody (e.g., on a label affixed to the package you're sending) and have them figure it out.
    - Dylan16807 12y ago
      Well sure, once you've separated name and country and postal code you've already pulled out most of the data. The blob has been tamed to 1-2 lines, and you're probably best off giving 'line 1' 'line 2' 'line 3' fields. At this point the chance of confusion is minimal, even if you can't validate very well.
    - walshemj 12y ago
      make sure its valid text - make sure you handle all the high asci characters and do something sensible with non Latin text. I once spent the best part of a day tracking down a problem with a single bad address for a major UK directory some how some one had entered an address in Egypt in Arabic.

curryhoward 12y ago

I think the consensus is to go with the "big blob of text" approach. You mentioned that postal workers are the only people qualified to parse addresses—let them do it. The validation done on your end shouldn't be much more than asserting that addresses contains non-whitespace characters. I don't know how well this works in practice, but it's the most "correct" thing to do.

DanBC 12y ago
I can understand not validating fields, but users are hopeless and like guidance. Giving them some structure in address fields helps the user through the system.
misterS 12y ago
> I don't know how well this works in practice, As soon as you don't control the whole thing end-to-end, i.e. from the user entering the data to printing it on an envelope: it won't work at all. It would require every program in the whole chain to accept this "big blob", which is simply not going to happen.
walshemj 12y ago
Bad mistake you get a metric fuck ton of shit in your data that way. You should always police your input data properly one big text field is lazy programming that leads to a big technical debt later on. And yes that does mean handling apostrophes and all those other edge cases properly.
- to3m 12y ago
  Name of recipient, state/province/etc., postal code and country, maybe. But for the rest, that bit (at least in the UK) that goes in the middle... what policing can you do? That part is just a text blob. You can't do much meaningful with it except for showing it to somebody (e.g., on a label affixed to the package you're sending) and have them figure it out.
  - Dylan16807 12y ago
    Well sure, once you've separated name and country and postal code you've already pulled out most of the data. The blob has been tamed to 1-2 lines, and you're probably best off giving 'line 1' 'line 2' 'line 3' fields. At this point the chance of confusion is minimal, even if you can't validate very well.
  - walshemj 12y ago
    make sure its valid text - make sure you handle all the high asci characters and do something sensible with non Latin text. I once spent the best part of a day tracking down a problem with a single bad address for a major UK directory some how some one had entered an address in Egypt in Arabic.