Naming Conventions

When reading code, does a name refer to a language function, a function defined by the programmer, a local variable, something displayed on a form ... And if the name is a variable, what type is it?

In general,

Use mixed case to improve readability
For components on a form, use a suffix to indicate both the component type and that the component is on the form (ie that it is a part of the User Interface). Such as
MyData_UIText
For variables, use suffixes to indicate their types.
(Basic has used this nomenclature since the beginning.)
For local temporary variables, other than strings, the suffixes are optional when the subroutine is short (< 2 screens). Specifically, the standard integer variables i, j, and k are always local variables without prefixes or suffixes.
Prefixes and suffixes are separated from the descriptive name using underscores.

Logical hierarchies which are not implemented or referenced using hierarchical dot notation should be named to indicate the hierarchical relationship. (For example, menus and toolbars in Visual Basic.) In these cases, place the hierarchy name first, then the variable name followed by the component type.

Many C users prefer to place a single letter variable type identifier first rather than last. Personally, I find that irritating because, when the variables are sorted, you can't find anything unless you remember what type a specific variable is. I prefer to remember just the variable's name and let the variable tell me its type. When extended to User Interface components, the same argument applies.

Visual Basic | Delphi | C++ Builder | Windows API

Visual Basic 6.0

All string names end with a dollar sign (temp$).

Menus

The menu system is basically an object hierarchy. Unfortunately, VB does not use object syntax to identify menu selections. Therefore, I suggest using the following hierarchical naming convention

UIMenu_File
UIMenu_File_Exit
UIMenu_Edit
UIMenu_Edit_Cut
UIMenu_Edit_Copy
UIMenu_Edit_Paste

This provides the advantage that the components sort in a logical manner.

The associated routines will be named similar to
UIMenu_File_Exit_Click()

ToolBars

A ToolBar is a frame (implemented using a PictureBox) which contains subordinate controls. In this case, prefix each subordinate control name with a common identifier and place an object type identifier at the end.

UIToolBar_UIPictureBox // This is the ToolBar object itself
UIToolBar_Display_UIButton
UIToolBar_Prev_UIButton
UIToolBar_Status_UITextBox

Delphi

Delphi is not case-sensitive.

The following definitions are followed but not enforced

TName	All type definitions begin with T
FProperty	The private class field used to store a property's value starts with F
OnMouseClick	Most event names begin with On
LVarName	Local variables, not usually used for single letter variable names - i, j, k, x, y, z
PVarName	A variable passed as a parameter. The Delphi VCL uses A instead of P. The common parameters Value and Message are used without a prefix.
PTName	Pointer to an object of type TName.

"A good guideline is that method names have verbs in them. If you find that you create a lot of methods that do not have verbs in their names, consider whether those methods ought to be properties." from the Delphi Help

Most property methods start with either Set or Get; events start with On.

For more details, see Guidelines for Writing Delphi Programs.

C++ Builder

C/C++ function and variable names are case-sensitive.

Windows API

Normally, I would say "If its predefined, then leave it alone!" However, in this case, your code can be made much more readable if you use the Windows API alias feature to rename DLL function calls to indicate what they are. I suggest a prefix such as

   winAPI_FuncName

Author: Robert Clemenzi - clemenzi@cpcug.org