Naming Conventions

Before we get into the particulars of how to name different elements in source code, there is one caveat about this: although Naming Conventions are excellent ways to disambiguate elements of code, sometimes Element Hierarchies are built into languages and/or database references that make Naming Conventions not strictly necessary;

For example, let's see how elements are organized using a language that has Packages (like JAVA J2SE 1.4) talking to a Relational Database (such as Oracle 10i):

1. Package (sub-directory) Name
2. Interface (file) Name
3. Class (file) Name
4. Class Method (function) Name
5. Oracle DBO (schema) Name
6. Oracle Database Name
7. Oracle Table Name

The JAVA (J2SE) language has some built-in ways to distinguish the name of a Package (which is similar to a NameSpace in C++ and other languages) from the name of an Interface or a Class;

For one thing, Packages use a same-named sub-directory to store Interface and Class files within the Package; So the limits of sub-directory naming applies to a Package Name — 32 characters being the length limit on most modern Operating Systems;

Also: JAVA requires all Class and Interface files begin with an <Include> statement with the name of any Packages. This architectural requirement makes it tough to confuse the hierarchy of names between Packages and Classes (or Interfaces.)

So, although you could take the trouble to name all Packages to start with a P_ and all Class names to start with a C_, this doesn't seem to be necessary within JAVA because of the way the language itself requires that such Names appear in different places in the source files.

However, JAVA is a language that provides the developer with Interfaces that can define the "public API" for each Class. So there might be a need to distinguish beteween Interfaces and Classes (which look similar), where an Interface Name might well start with an 'I_' and a Class Name start with a 'C_'.

The Oracle RDBMS (Relational Database Management System) is a high-end database that uses schemas to distinguish groups of databases that might have particular purposes. And the way Oracle users can distinguish a schema of databases, is simply to use the built-in dot notation that is used to separate databases from tables. For example, if there is a Schema such as 'dbo', you can reference a table within it like this:

dbo.myDatabase.myTable

So we might say that Oracle has no need to for a Naming Convention requiring a Schema to look different from a Database or Table because a schema always appears FIRST in such a reference as the above.

And if there are three names within a dot-notated name such as the above, you know automatically that the first one is the Schema, the middle one is the Database, and the last one is the Table.

Most languages that provide static classes now allow you to use notation that specifies whether the call to a Class Method statically or invoke the call on a particular object instance; So this is one way the language itself would seem like it is helping you. For example:

// calling a static method directly:

C_MyClass::myStaticMethod();

// calling an automatic (non-static) method
// using an object instance of the class:

C_MyClass myObject = new C_MyClass();
myObject->myNonStaticMethod();

So you might think that there is no need to disambiguate static methods from non-static methods; But this is actually a case where a Naming Convention can help. How do you know whether you could use the static call from outside the class without having access to the Class Definition? If you used a naming convention, it would be readily apparent from the public API Interface.

For Example:

// static method naming:

mStat_method1(); // or
sm_method1();

// automatic (non-static) method naming:

m_method2();

The point of using Naming Conventions is to disambiguate elements when it helps; this page is here to remind you that not every element needs it in every development situation. So now, without further ado...let's examine some Naming Conventions that are in practical use today...