- Names representing types must be in mixed case starting with upper case.<code>
Line, SavingsAccount</code>
  - Variable names must be in mixed case starting with lower case.<code>
 line, savingsAccount </code>
  - Named constants (including enumeration values) must be all uppercase using underscore to separate  words.<code>
 MAX_ITERATIONS, COLOR_RED, PI </code>
  - Names representing methods or functions must be verbs and written in mixed case starting with  lower case.<code>
 getName(), computeTotalWidth() </code>
  - Names representing namespaces should be all lowercase.<code>
 model::analyzer, io::iomanager, common::math::geometry </code>
  - Names representing template types should be a single uppercase letter.<code>
 template<class T> ... template<class C, class D> ... </code>
  - Abbreviations and acronyms must not be uppercase when used as name [4].<code>
 exportHtmlSource(); // NOT: exportHTMLSource(); openDvdPlayer(); // NOT: openDVDPlayer(); </code>\\ Using all uppercase for the base name will give conflicts with the naming conventions given above. A variable of this type whould have to be named dVD, hTML etc. which obviously is not very readable.\\ Another problem is illustrated in the examples above; When the name is connected to another, the readbility is seriously reduced; the word following the abbreviation does not stand out as it should.
  - Global variables should always be referred to using the :: operator.<code> 
 ::mainWindow.open(), ::applicationContext.getName() 
In general, the use of global variables should be avoided. Consider using singleton objects instead.</code>
   - Private class variables should have underscore suffix.<code>
 class SomeClass { private: int length_; } </code>
  - Generic variables should have the same name as their type.<code>
 void setTopic(Topic* topic) // NOT: void setTopic(Topic* value) // NOT: void setTopic(Topic* aTopic) // NOT: void setTopic(Topic* t) void connect(Database* database) // NOT: void connect(Database* db) // NOT: void connect (Database* oracleDB) 
Non-generic variables have a role. These variables can often be named by combining role and type: 
 Point  startingPoint, centerPoint;
 Name   loginName;</code>
  - All names should be written in English.<code>
 fileName; // NOT: filNavn </code>
  - Variables with a large scope should have long names, variables with a small scope can have short names [1].\\ Scratch variables used for temporary storage or indices are best kept short. A programmer reading such variables should be able to assume that its value is not used outside a few lines of code. Common scratch variables for integers are i, j, k, m, n and for characters c and d. 
  - The name of the object is implicit, and should be avoided in a method name.<code>
 line.getLength(); // NOT: line.getLineLength(); </code>
  - The terms get/set must be used where an attribute is accessed directly.<code>
 employee.getName(); employee.setName(name); matrix.getElement(2, 4);
  - The term compute can be used in methods where something is computed.<code>
 valueSet->computeAverage(); matrix->computeInverse() 
this is a potential time consuming operation, and if used repeatedly, consider caching the result.
  - The term find can be used in methods where something is looked up.<code>
 vertex.findNearestVertex(); matrix.findMinElement(); 
this is a simple look up method with a minimum of computations involved. </code>
  - The term initialize can be used where an object or a concept is established.<code>
 printer.initializeFontSet(); </code>
  - Variables representing GUI components should be suffixed by the component type name.<code>
 mainWindow, propertiesDialog, widthScale, loginText, leftScrollbar, mainForm, fileMenu, minLabel, exitButton, yesToggle etc. </code>
  - Plural form should be used on names representing a collection of objects.<code>
 vector<Point> points; int values[]; </code>
  - The prefix n should be used for variables representing a number of objects.<code>
 nPoints, nLines 
  - The suffix No should be used for variables representing an entity number.<code>
 tableNo, employeeNo 
An elegant alternative is to prefix such variables with an i: iTable, iEmployee. This effectively makes them named iterators. </code>
  - Iterator variables should be called i, j, k etc.<code>
 for (int i = 0; i < nTables); i++) { : } for (vector<MyClass>::iterator i = list.begin(); i != list.end(); i++) { Element element = *i; ... } </code>
  - The prefix is should be used for boolean variables and methods.<code>
 isSet, isVisible, isFinished, isFound, isOpen 
There are a few alternatives to the is prefix that fits better in some situations. These are the has, can and should prefixes: 
  bool hasLicense();
  bool canEvaluate();
  bool shouldSort();</code>
  - Complement names must be used for complement operations [1].<code>
 get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end, first/last, up/down, min/max, next/previous, old/new, open/close, show/hide, suspend/resume, etc. </code>
  - Abbreviations in names should be avoided.<code>
 computeAverage(); // NOT: compAvg(); </code>
  - Naming pointers specifically should be avoided.<code>
 Line* line; // NOT: Line* pLine; // NOT: LIne* linePtr; </code>
  - Negated boolean variable names must be avoided.<code>
 bool isError; // NOT: isNoError bool isFound; // NOT: isNotFound </code>
  - Enumeration constants can be prefixed by a common type name.<code>
 enum Color { COLOR_RED, COLOR_GREEN, COLOR_BLUE }; 
An alternative approach is to always refer to the constants through their common type: Color::RED. </code>
  - Exception classes should be suffixed with Exception.<code>
 class AccessException { : } </code>
  - Functions (methods returning something) should be named after what they return and procedures (void methods) after what they do.'''