Namespace Management and Conventions

Namespace Management and Conventions

The key goal is to avoid "namespace pollution". That is, consume as little of your client's namespace as is practical, and document what you're consuming. This minimizes conflicts with user code, third party products, and other projects. Names should also trade off brevity and clarity appropriately. Also, no code names must appear in the final product.

All namespace usage should be unique, so no two projects conflict. For example, almost any two libraries (bundled or unbundled) should be compatible. (I.e., customers should not be precluded from using them simultaneously due to a name collision. Avoid using any standard's namespace for Sun-defined nonstandard interface additions, to avoid conflict with future standard revisions.

Pick one prefix (or a very few prefixes) to reserve for use by the library and its header files--including compile-time symbols (#defines or #ifdefs) defined by or used by the project. The prefixes may be used with varying capitalization (CAPS for #defines, etc.). Any symbols not prefixed will need explicit justification. Test for any such symbols.

A secondary goal is to avoid gratuitous creation of new namespaces. If there a public namespace (i.e., if third parties can create names in your namespace), how will this administered?

As a special case, RPC protocols must be registered via E-mail to rpc at sun dot com.