The basic solution can be read as, Decide the API that you want to program to, create a compatibility layer that supports that API for each platform, program to that compatibility layer. In the simple case the compatibility layer is trivially simple in one case.

If you'll read [link|http://www.oreilly.com/catalog/opensources/book/linus.html|http://www.oreilly.c...s/book/linus.html] you'll note that the solution within Linux for how to support so many architectures takes this exact form, again.

In this case you can follow a strategy like this (written in Perl, badly):

\n# A badly done compatibility layer.\nmy $DATABASE;\nif ($IS_DEVELOPMENT) {\n  ...\n  $DATABASE = 'DEV';\n  ...\n}\nelse {\n  ...\n  $DATABASE = 'PROD';\n}\n\n# and outside of the compatbility layer...\nmy $dbh;\nsub open_connection {\n  unless ($dbh) {\n    # If somebody typoed, there will be no database\n    # to connect to of the name this gets, and things\n    # will (properly) blow up.\n    $dbh = open_database($DATABASE);\n  }\n  return $dbh;\n}\n

Now the error that you had becomes very different. Getting the variable name wrong somewhere results in an instant highly visible crash.

The flaws in how I've written this are many.

For one thing you often want to support cascading defaults since many configuration variables should be the same in development and production. But cascading defaults open you up again to accidentally having something cascade that shouldn't. Therefore have both development and production cascade back to sane defaults. Most configuration items go into the defaults. The few that have to differ do not go into the defaults.

For another you're likely to need at least 3 environments some day. (Development, staging, production.) Build that flexibility in. I've seen multiple ways of doing that. One of the better ones is to build up a hash of hashes. Each sub-hash is a possible configuration. The outer hash is a mapping of environment to configuration variables. In building it up, you make some sub-hashes start as copies of others - right there you have your cascading logic! That is very nice if you, for instance, want to give each developer their own machine with a customized installation to play with.

But for all of its flaws, the above demonstrates the key idea. Have a section devoted to configuration information only. Then don't scatter if-tests around. Instead have other functions that act in a very generic way upon the configuration data.

Cheers,
Ben