This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Svelte and Sapper in Action and have Mark Volkmann on-line!
See this thread for details.
Win a copy of Svelte and Sapper in Action this week in the 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown
  • Mark post as helpful
  • send pies
  • 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.

    If a regular clown is funny, then a larger clown would be funnier. Math. Verified by this tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
      Bookmark Topic Watch Topic
    • New Topic