Data Model > Extending the UNICOM Intelligence Data Model > Creating a CDSC > Development standards > Naming conventions
 
Naming conventions
The naming conventions used by UNICOM Intelligence in the development of the UNICOM Intelligence Data Model are based on Microsoft's Hungarian naming conventions. By following these conventions, code generated by Microsoft wizards automatically uses the correct naming standards.
The goal of the naming conventions is to:
Identify type from the name
Identify scope from the name
Help create consistent method names
Provide additional guidelines for classes, constants, and enumerations
Identifying variable type
Using Hungarian notation, variable names begin with one or more lowercase letters that denote the variable type. This provides an inherent identification. For example, the prefix h is used to identify a handle: such as hWnd or hDlg, which refer to window and dialog box handles, respectively. The following table shows the type prefixes that are used.
Prefix
Data type
a
array
b
boolean
by
byte or unsigned char
c
char
cx / cy
short used as size
d
double
dw
DWORD, double word or unsigned long
f
float
fn
function
h
handle
hr
HRESULT
i
int (integer)
l
long
map
STL map
n
short int
p
pointer (lp can also be used)
str
string
sz
null-terminated string
vt
VARIANT
vec
STL vector
w
WORD unsigned int
x, y
short used as coordinates
New prefixes can be introduced to a code module or component provided the usage is consistent. If appropriate, custom prefixes should use the actual type name. This helps to avoid duplicate type prefixes. For example, the following variable declaration can be used:
CRow rowCurrent;
In some situations, it is appropriate to create a variable using the type qualifier only. For example, variables i and hr can be used as follows:
HRESULT hr;
for(int i=0; i<10; i++)
hr = pISomeInterface->Method(i);
The p and a type prefixes are often combined with other prefixes to further define the variable type. For example, a string pointer should use the prefix psz and an array of ints should use ia.
Identifying variable scope
To help differentiate between variables defined at function scope, module scope, or global scope, additional prefixes are used. The following table provides a summary of the scope prefixes.
Scope
Prefix
Examples
local
none
DWORD dwStart;
module / class
m_
ITable *m_pITable;
global
<Uppercase Module Prefix>_
MAIN_appModule;
Note While global variables are not encouraged, there are sometimes good reasons to use them. For further information, refer to Code Complete by Steve McConnell, page 228.
Method naming conventions
The type prefix conventions do not work well for methods. Some methods do not take parameters or do not return values. Guidelines for naming methods are:
Always start a method name with a capital and if possible, do not use underscores in the name. This helps to distinguish method names from variable names.
Express the action of the method in one or two words, typically transitive verbs. Punctuate the words by using initial capitals for each word.
The following table provides some examples of method names.
Name
Description
InitSy
Takes a sy as its argument and initializes it.
OpenFn
fn is the argument. The method will "open" the fn.
FcFromBnRn
Returns the fc corresponding to the bn,rn pair given.
Additional naming guidelines
The following guidelines are used:
Preprocessor macros and constants
Use uppercase letters only and the underscore(_) character as a separator. For example, START_POSITION.
Class names
Prefixed with C. For example, CMyClass.
Enumerated values
Use a prefix to indicate which enumeration they come from. For example, langILANGUAGE (from the LanguageConstants enumeration).
See also
Component development
Coding standards
Layout
Comments
String handling
Dealing with existing source code
Class library usage
Best practice
Development standards