You've probably heard the phrase "don't re-invent the wheel", and computer courses are generally pretty good at teaching you how to avoid it when you're writing code. But what about data?
It's remarkable how often even experienced programmers dream up weird and wonderful - and bad - systems for codifying things such as countries or colours or currencies, when there's already a perfectly good established standard available.
Furthermore, those standards usually include all the information you need for validation (even if it's just checking a list). So if you find yourself needing to write a class/program that deals with credit card numbers, start by reading up onISO 7812.
Here's just some of the things you might need to codify or validate when you write a program. It's by no means complete, but hopefully it gives you some idea of what's out there:
Countries: ISO 3166 - Also includes subdividions (eg, provinces and states).
Airports: IATA code - These can also be very useful for codifying things such as cities, offices, and server or warehouse locations, since almost every major city in the world has at least one airport, and people are often familiar with their local code (mine's "BRU").
Don't be intimidated by the size of the list - I simply provide it as somewhere to start looking; but do look first.
The chances are that if you need to codify something, you won't be the first; and using an existing standard greatly increases the chances of your program being compatible with others that deal with the same thing, allowing you to share information with a minimum of effort.
You also benefit from all the usual things you get from re-use:
Expertise: Most established standards have been developed by teams of experts over many years, so they will probably have thought through the subject far more than you ever will.
Documentation: Do you really want to document an existing system all over again? If you use an established standard, all you need to do is to say something like: "An ISO-3166 alpha-2 country code" and your job is done.
Familiarity: Recognised standards are often already established practise for the people who will use your software. Unfortunately, "established practise" can be a double-edged sword, since it may also involve home-grown "standards"
Durability: Good standards allow scope for growth, allowing a system that was originally planned, for example, for a local company to "go global" or, as outlined above, share information with other, larger systems, with very little effort.
The only other piece of advice I can give is that if you find two conflicting standards that cover the same ground, use the one that is most specific, or most applicable to your need.
For example: Both ISO-3166 and E.164 contain "country numbers" and they are not compatible. The first is primarily a standard for internationally recognised countries; the latter is a routing prefix for telephone dialling, so it contains, for example, 881 for the Global Mobile Satellite System; and the prefix '1' is shared by both Canada and the US.
Yes, it does take a bit of extra thought; but what you'll probably find is that you create a class (eg, TelephoneNumber) as you find a need, so you'll be dealing with them individually. And of course, once you've written your class, you can re-use it whenever you need to.