Portability Issues

Programming is difficult. All programmers know the frustration of trying to get a program to work accordig to specification. But one thing that really defines the professional programmer is the ability to write portable programs that will work on a variety of systems.

--- Peter Norvig, Paradigms of Artificial Intelligence Programming

• Be clear about the distinction between the specification and implementation of the facilities and packages you use. Don't write code that depends on implementation-specific details subject to change. (Some novice programmers seem to take special delight in writing code that depends on obscure implementation details.)
• Don't use other packages frivolously: Users should not have to to find and install a package just to make one of your error messages prettier, say. (This doesn't mean you should replicate complete other packages inside your own just to eliminate dependencies on other packages, of course!)
• Don't export symbols frivolously: This clutters the namespaces of packages using your package, and may force them to inport symbols one by one if there are too many name clashes with other packages in use. Try to find a design with a reasonably small number of exported symbols. If you need to export symbols unlikely to be used very often, give them long descriptive names less likely to clash with symbol names from other packages.
• Look for ways to deduce system-dependent information at installation time or on the fly, or else accept it as a parameter, rather than embedding such dependencies in your package code.
• If you must depend on some system-dependent property, such as the location of a particular external resource, confine this dependency to a single global variable or such, don't scatter it repeatedly all through your code.

Go to the first, previous, next, last section, table of contents.