Naming and Coding Conventions

All properties within a class are given meaningful names that begin with a capital letter and all subsequent words capitalised. For example, a property corresponding to the border colour of a Rectangle would be given the name BorderColour. In the cases where capitalisation of words does not work well an underscore is used to break entities. For example, a graph class that has an attribute corresponding to the x-axis might be given the property name X_Axis instead of XAxis. Each property in a class may typically have accessors to get and set property values. Here we use method overloading to provide safe access to properties with the name of the accessor methods taking on the name of the property except that the first letter is always lowercase. This lower case convention is also universally applied to all methods in a class. The only exception to this rule is constructors and destructor for obvious reasons. For example the accessor methods for BorderColour would be defined as,

const GuiColour&    borderColour() const;
void                borderColour(const GuiColour& rColour);

Note that appropriate use of const is used throughout AtOne. Any accessor retrieving a value will generally always be a const method returning a const reference (or pointer). The only deviation from this convention is in the case of trivial intrinsic types (int, short, char etc) in which the property is returned by value (for efficiency reasons). 

Within method implementations local variable naming conventions are generally free form (whatever you like). Generally though, all local variables are given meaningful names and all variables of simple intrinsic type use a simplified Hungarian style notation with,
 
 

prefix	variable type
n	char, short, long, int (signed or unsigned)
p	object*, char*, short*, long*, int* (signed or unsigned)
r	object&, char&, short&, long&, int& (signed or unsigned)

Generally local objects (class instances) are not given any special prefix. Also loop counters or general counter variables are given a c prefix and a short name. Commonly used examples include cn, cm, cx and cy. 

Users of MFC may find this coding convention rather strange, however, we believe this convention is much more appropriate in object oriented programming than the MFC coding convention. Hungarian notation in C++ is anathema because C++ is a type safe language. The Hungarian notation essentially adds redundant unecessary information to the code. MFC typically also uses a m_ and g_ notation to indicate members and globals within code. I feel however, that global variables should generally never be used in good object oriented programming. If a global is needed it should be bound to a class as a static member. For instance a good technique for gaining access to a global variable is to have a wrapper class in which you can use a constructor to set the value and a casting operator and default constructor to read the value. This approach is generally used in AtOne where global variables are require. Using this approach global variables are always members of a class and therefore the g_ prefix becomes redundant. Then since members always conform to the above naming convention and all variables are either local to a member function or class members I feel the m_ also becomes redundant. Some friends have argued that the m_ is still relevent because it helps to discriminate between local and member variables. However, it is generally accepted that in good object oriented programming methods should be simple and short. That generally being the case coupled with the simplified Hungarian notation used for local variables makes it possible to very quicky identify which variables are members and which are not (without and explicit m_). Only in very complex methods (which should be few) does it become difficult and in such cases the code must be carefully studied before modification in any case and more importantly, should preferably be split up into multiple methods. It seems odd to me to penalise the free flowly inteligibility of object oriented code for the sake of generally poor programming practice, hence the described coding convention is adhered to, resulting in, what I feel is very readable and maintainable code. Where  this coding convention will break down is in the case of lazy programmers creating very abreviated generally meaningless names for properties, classes and methods. For example, where I create a property name of StatusTriggerIndicator they might use m_StatTrigInd. After six months without seeing the code which is more likely to have meaning to you? No coding convention will help the inteligibility of code written by lazy programmers!
 

 Commonly Used Classes

Paavo Jumppanen
Creator of AtOne Application Framework