Naming Conventions: Difference between revisions
m (→Namespaces) |
(→Enums) |
||
Line 48: | Line 48: | ||
* TypePrefix_SomeName | * TypePrefix_SomeName | ||
* TypePrefix_SomeOtherName | * TypePrefix_SomeOtherName | ||
* | * TypePrefix_AndSomeMore | ||
The TypePrefix should be chosen appropriately for the purpose of the enum. Don't use all uppercase names. These would make the enums look like preprocessor constants. | The TypePrefix should be chosen appropriately for the purpose of the enum. Don't use all uppercase names. These would make the enums look like preprocessor constants. |
Revision as of 06:28, 22 October 2015
In the beginning of OpenMW we did not had any naming conventions which resulted in substantial inconsistencies. This page tries to codify the conventions that are most commonly used in the code base. Please stick to them, even if the code in the neighbourhood of what you are working on is not.
Files
header files: somefile.hpp
source files: somefile.cpp
No CamelCase and no underscores, please.
Names
Namespaces
Example: ThisIsANamespace
Namespaces in apps/openmw will have a MW-prefix (MWThisIsANamespace). Obviously you should try to keep these names short, but don't use hard to read abbreviations.
Classes
Example: ThisIsAClass
Functions
Example: thisIsAFunction
Local Variables & Parameters
Example: thisIsAVariable
Member Variables
Non-static: mThisIsAVariable
Static: sThisIsAVariable
Note that formally the name of the variable would still be thisIsAVariable. The m and the s are scope sigils. Some other languages (e.g. Ruby) provide these as part of the syntax. C doesn't, so we have to encode them in the name. And no, this is not Hungarian notation.
Global Variables
Shame on you!
Enums
Example:
- TypePrefix_SomeName
- TypePrefix_SomeOtherName
- TypePrefix_AndSomeMore
The TypePrefix should be chosen appropriately for the purpose of the enum. Don't use all uppercase names. These would make the enums look like preprocessor constants.
Preprocessor constants
Example: THISISACONSTANT
Since preprocessor constants are the only part of the language that does not respect namespaces, these must be clearly distinguished from everything else.
Don't use these for anything but include guards and conditional compiling.
Acronyms
Acronyms in names should follow the guidelines on this page too, even if that is not how you would normally write them, e.g.: a class representing a NPC would be called Npc. Otherwise it would look like a preprocessor macro.
Abbreviations
Please avoid cryptic abbreviations. iter and i are okay. Well known acronyms from the RPG terminology are okay too (but see above for advice on capitalisation). Other abbreviations should be avoided. Don't be afraid of long names!