This week's book giveaways are in the AI and JavaScript forums.
We're giving away four copies each of GANs in Action and WebAssembly in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of GANs in ActionE this week in the AI forum
or WebAssembly in Action 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 ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger
  • 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.




    CategoryWinston
     
    Politics is a circus designed to distract you from what is really going on. So is this tiny ad:
    Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
    https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
      Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!