CodeConvention
Neon Code Convention
General rules:
- Use doxgen for documentation with Javadoc style comment block i.e.,
-
Use inline documentation of the function input variables and class members variables e.g.,
-
using namespaceis only allowed inside.cpp/.cufiles. It’s disallowed in headers. -
using namespace stdis disallowed even in.cpp/.cufiles. If you want to save some work, just typedef the type you need from the std namespace, or useauto. -
For consistency reasons, use
usingdeclaration instead oftypedefe.g., -
Use only sized types (e.g.,
int32_t,uint32_t,int16_t). Conceptually,boolhas unknown size, so no size equivalent.charis special and can be used only for C strings (useint8_totherwise). -
Don’t use
NULLor 0 to initialize pointers.nullptris part of the language now. -
Preprocessor definitions are all capitals and may contain
_e.g.,c++ #define SOME_DEFINE -
Don’t use long line comment separator e.g.,
/////////////or/*****************/ -
We use
NEON_TRACE,NEON_INFO,NEON_WARNING,NEON_ERROR, andNEON_CRITICALfor logging. Usingprintforstd::coutis prohibited.NEON_*logging macro rely onspdlogwith easy python-like string formatting e.g.,
Variable prefixes:
Use the following prefixes for variable names based on the scope s, m, g, and k. These are mutually exclusive prefixes, where k takes precedence above the rest.
- k for compile-time const variables.
- g for global variables, including static global variables.
- s for class static variables.
- m for member variables in classes (not in structs).
In addition p is used for pointers e.g.,
Functions:
-
Use auto style for function but explicitly defining the return type using trailing arrow e.g.,
-
Function names should be descriptive:
- Functions that perform an action should be named after the action it performs e.g.,
Fbo::clear(),createTextureFromFile(). - Getters/Setters should start with
getandset -
Functions names that return a
boolshould be phrased as a question e.g.,isWhite(),doesFileExist(),hasTexture() -
Function names are lower-camel-case e.g.,
Classes:
-
Classes should hide their internal data as much as possible.
-
Class names should be Upper Camel case (
UpperCamelClass) or Lower Camel case (lowerCamelClass)
-
Header file must be a
.hcontaining only the class declaration i.e., class name, methods’ signature and variables -
Source file must be a
.cppor.cuand it contains the definition of all methods -
Templated methods definition must be in separate
.hfile that is included by the corresponding.h. File name should end with_imp.h -
File names only contain dot (“.”) before the file extension suffix
-
Each class has it’s own files with same name e.g.,
Gridclass goes intoGrid.h,Grid.cpp, andGrid_imp.h -
The order of public/private members and methods as they appear in the class
.hfile is:- public members
- public methods
- private methods
- private members
Structs:
Use struct only as a data-container. All fields must be public. No member functions are allowed. In-class initialization is allowed.
Enums:
Use typed enums (i.e, enum class) as they are type safe and they automatically define their namespace. When approperiate, each enum class should be followed by utility class with static methods. These utility method provide a toString() funtionality as well as toInt() for easy conversions.