Programme Naming Conventions

The first rule of naming is that names should add to the reader's understanding rather than obscuring it. For example, The name of a function that returns an element of an array should be something like GetNextCustomer() rather than GetNextArrayElement().

Some other general points about naming...

• If you have difficulty in finding an appropriate name for a function, procedure or object then you may need to further analyse or define the purpose of that item.
• Names should be long enough to be meaningful but no longer.
• Remember that names have no meaning to the compiler/interpreter other than to distinguish one item from another.

Some rules that you may wish to follow include...

• Use mixed case to aid readability. Capitalise the first letter of each word in a function or procedure name and the same for variable names but with the very first character in lower case. Thus a procedure might be called SortNewCustomers while a variable migh be called customerName.
• Use all capitals with words seperated by underlines for constants as in TOTAL_SHOPS or SALES_BAND_A.
• Don't use names that are ambiguous, such as AnalyzeThis() for a routine, or A47 for a variable. 
• Don't include class names in the names you give to class properties, such as Customer.CustomerID. Instead, use Customer.ID.
• If a routine performs an operation on a given object, include the object name in the routine's name, as in ValidateCustomerID().
• Never overload a function in such a way that it performs     * In languages that permit function overloading, all overloads should perform a similar function. For those languages that do not permit function overloading, establish a naming standard that relates similar functions.
• Where a variable holds the result of a computation, add the type of computation to the end of the variable name as in salesAvg, customerSum, temperatureMin, temperatureMax, customerIndex) and so on.
• When producing complementary pairs of variables, name them appropriately, e.g. min/max, begin/end or open/close.
• If a variable is Boolean i.e. it contains only Yes/No or True/False values, use a name which highlights this such as fileIsFound or customerIsValid.
• Avoid the lazy use of terms like Flag when naming status variables. Instead of documentFlag, use a more descriptive name such as documentFormatType.
• Always avoid single character variable names in loops and so on. "for ThisShop = 1 to TOTAL_SHOPS" is far more informative than "for i = 1 to 23"
• Never use literals for constants. Always assign values to constants in a single place at the top of the programme for the good and sufficient reason that constants need changing surprisingly often!

Some points that apply particularly to database handling...   

• When naming tables, express the name in the singular form. For example, use Employee instead of Employees.
• When naming columns of tables do not repeat the table name; for example, avoid a field called EmployeeLastName in a table called Employee.
• Do not incorporate the data type in the name of a column. This will reduce the amount of work should it become necessary to change the data type later.
• Do not prefix stored procedures with sp, which is generally a prefix reserved for identifying system stored procedures.
• Do not prefix user-defined functions with fn_, which is generally a prefix reserved for identifying built-in functions.
• Do not prefix extended stored procedures with xp_, which is generally a prefix reserved for identifying system extended stored procedures.

Other points you may wish to consider...

• Don't abbreviate unless you must. If you do, use those that you have created consistently. Any abbreviation should have only one meaning and likewise, each abbreviated word should have only one abbreviation. For example, if you use min to abbreviate minimum, do so everywhere and do not use min to also abbreviate minute.
• When naming functions, include a description of the value being returned, such as GetCustomerName().
• File and path names should also accurately describe their purpose such as SalesTransferFile or SalesFileDirectory.
• Don't use easily confused names for multiple items. Especially avoid confusions such as a routine called ProcessSales() and a variable loaded from it called iProcessSales.
• Try to avoid words that sound the same (homonyms), such as 'write' and 'right'. They can lead to all sorts of confusion when several people work on a project.
• Use the appropriate spelling for your contry such as color/colour or check/cheque.
• It's no longer considered valid to use character type identifiers, such as $ for strings or % for integers as various languages, such as Perl, reserve these symbols.