Naming conventions

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 */
};
typedef int *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, const char *address, const char *message);