mgenay:technique:cppnamingconvention

Names representing types must be in mixed case starting with upper case.
```
Line, SavingsAccount
```
Variable names must be in mixed case starting with lower case.
```
 line, savingsAccount 
```
Named constants (including enumeration values) must be all uppercase using underscore to separate words.
```
 MAX_ITERATIONS, COLOR_RED, PI 
```
Names representing methods or functions must be verbs and written in mixed case starting with lower case.
```
 getName(), computeTotalWidth() 
```

Names representing namespaces should be all lowercase.

 model::analyzer, io::iomanager, common::math::geometry

Names representing template types should be a single uppercase letter.
```
 template<class T> ... template<class C, class D> ... 
```
Abbreviations and acronyms must not be uppercase when used as name [4].
```
 exportHtmlSource(); // NOT: exportHTMLSource(); openDvdPlayer(); // NOT: openDVDPlayer(); 
```
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.

 
 ::mainWindow.open(), ::applicationContext.getName() 
In general, the use of global variables should be avoided. Consider using singleton objects instead.

Private class variables should have underscore suffix.
```
 class SomeClass { private: int length_; } 
```

Generic variables should have the same name as their type.

 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;

All names should be written in English.
```
 fileName; // NOT: filNavn 
```
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.
```
 line.getLength(); // NOT: line.getLineLength(); 
```

The terms get/set must be used where an attribute is accessed directly.

 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.

The term initialize can be used where an object or a concept is established.
```
 printer.initializeFontSet(); 
```

Variables representing GUI components should be suffixed by the component type name.

 mainWindow, propertiesDialog, widthScale, loginText, leftScrollbar, mainForm, fileMenu, minLabel, exitButton, yesToggle etc.

Plural form should be used on names representing a collection of objects.
```
 vector<Point> points; int values[]; 
```

The prefix n should be used for variables representing a number of objects.

 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.

Iterator variables should be called i, j, k etc.

 for (int i = 0; i < nTables); i++) { : } for (vector<MyClass>::iterator i = list.begin(); i != list.end(); i++) { Element element = *i; ... }

The prefix is should be used for boolean variables and methods.

 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();

Complement names must be used for complement operations [1].

 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.

Abbreviations in names should be avoided.
```
 computeAverage(); // NOT: compAvg(); 
```

Naming pointers specifically should be avoided.

 Line* line; // NOT: Line* pLine; // NOT: LIne* linePtr;

Negated boolean variable names must be avoided.

 bool isError; // NOT: isNoError bool isFound; // NOT: isNotFound

Enumeration constants can be prefixed by a common type name.

 enum Color { COLOR_RED, COLOR_GREEN, COLOR_BLUE }; 
An alternative approach is to always refer to the constants through their common type: Color::RED.

Exception classes should be suffixed with Exception.
```
 class AccessException { : } 
```
Functions (methods returning something) should be named after what they return and procedures (void methods) after what they do.'''