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?
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.
- 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).
- 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
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
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 6.0
All string names end with a dollar sign (temp$).
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
This provides the advantage that the components sort in
a logical manner.
The associated routines will be named similar to
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
Delphi is not case-sensitive.
The following definitions are followed but not enforced
"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
||All type definitions begin with T
||The private class field used to store a property's value
starts with F
||Most event names begin with On
||Local variables, not usually used for single letter
variable names - i, j, k, x, y, z
||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.
||Pointer to an object of type TName.
Most property methods start with either
Set or Get;
events start with
For more details, see
Guidelines for Writing Delphi Programs.
C/C++ function and variable names are case-sensitive.
Normally, I would say "If its predefined, then leave it alone!"
However, in this case, your code can be made much more readable
use the Windows API alias feature to rename DLL function calls
to indicate what they are.
I suggest a prefix such as
Author: Robert Clemenzi -