Win a copy of React Cookbook: Recipes for Mastering the React Framework this week in the HTML Pages with CSS and JavaScript forum!
    Bookmark Topic Watch Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Frits Walraven
  • Himai Minh
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
(Level: Beginner/Intermediate)

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 on ISO 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).
  • Currencies: ISO 4217.
  • Languages: ISO 639.
  • Bank/Credit cards: ISO 7812.
  • Books: ISO 2108 - Otherwise known as "ISBN".
  • Music: ISWC (related to ISBN), ISRC, and others.
  • Quantities, weight and measures: ISO/IEC 80000 - Supercedes ISO 31 and part of IEC 60027, and incorporates most of the SI unit system.
  • Telephone numbers: E.164.
  • Vehicles: VIN numbers and License plates.
  • Products and Barcodes: GTIN - Also contains references to UPC and EAN codes.
  • Colours: ISCC-NBS or X11 - or indeed, just use one of the constants in the Color class.
  • Stream content: MIME.
  • File content: Filename extensions and Magic Numbers - Unfortunately, neither is yet a proper standard.
  • 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").

  • And for other stuff? - Google is your friend.


    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.

    And that's what Object-Orientation is all about.

    Think of how dumb the average person is. Mathematically, half of them are EVEN DUMBER. Smart tiny ad:
    the value of filler advertising in 2021
      Bookmark Topic Watch Topic
    • New Topic