Here are some suggestions for a naming convention. These help identify the variables usage and type and so reduce coding errors. This is an abridged Hungarian notation, where your variables have the following structure:
[<scope>_]<type><name>
<scope> identifies the scope of the variable. Recommended scope values are in the table below:
Prefix
|
Variable scope
|
m
|
instance class members
|
c
|
static class members (including constants)
|
g
|
global static variable
|
<empty>
|
local variable or struct, or public class member
|
<type> identifies the data type of the variable. Recommended type values are in the table below:
Prefix
|
Data type
|
b
|
Boolean
|
by
|
byte or unsigned char
|
cx/cy
|
short used as size
|
dw
|
DWORD, double word or unsigned long
|
fn
|
Function
|
h
|
Handle
|
i
|
int (integer)
|
l
|
Long
|
p
|
a pointer
|
s
|
String
|
sz
|
ASCIIZ null-terminated string
|
w
|
WORD unsigned int
|
x,y
|
short used as coordinates
|
<name> describes how the variable is used, or what it contains. The <scope> and <type> portions should always be lowercase, and the <name> should use mixed case. Some recommended complete variable names, including the scope and type prefixes along with the name, are in the table below:
Variable name
|
Description
|
m_hWnd
|
a handle to a HWND
|
ipEnvelope
|
a smart pointer to a COM interface
|
m_pUnkOuter
|
a pointer to an object
|
c_isLoaded
|
a static class member
|
g_pWindowList
|
a global pointer to an object
|
Type names
All type names (class, struct, enum, and typedef) begin with an uppercase letter and used mixed case for the rest of the name. See the following examples:
[C++]
class Foo: public CObject
{
/* definition here */
};
struct Bar
{
/* definition here */
};
enum ShapeType
{
/* definition here */
};
typedefint *FooInt;
Typedefs for function pointers (callbacks) append Proc to the end of their names, as shown in the following code:
[C++]
typedef
void(*FooProgressProc)(int step);
Enumeration values all begin with a lowercase string that identifies the project; in the case of ArcObjects this is esri, and each string occurs on separate lines, as shown in the following code:
[C++]
typedef
enum esriQuuxness
{
esriQLow;
esriQMedium;
esriQHigh;
esriQuuxness;
}
Function names
Name functions using the following conventions:
For simple accessor and mutator functions, use Get<Property> and Set<Property>:
[C++]
int GetSize();
void SetSize(int size);
If the client is providing storage for the result, use Query<Property>:
[C++]
void QuerySize(int &size);
For state functions, use Set<State> and either Is<State> or Can<State>:
[C++]
bool IsFileDirty();
void SetFileDirty();
bool CanConnect();
Where the semantics of an operation are obvious from the types of the arguments, leave type names out of the function names.
Instead of
[C++]
AddDatabase(Database &db);
consider using
[C++]
Add(Database &db);
If a client relinquishes ownership of some data to an object, use Give<Property>. If an object relinquishes ownership of some data to a client, use Take<Property>:
[C++]
void GiveGraphic(Graphic *graphic);
Graphic *TakeGraphic(int itemNum);
Use function overloading when a particular operation works with different argument types:
[C++]
void Append(const CString &text);
void Append(int number);
Argument names
Use descriptive argument names in function declarations. The argument name should clearly indicate what purpose the argument serves:
[C++]
bool Send(int messageID, constchar *address, constchar *message);