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 namespace
is only allowed inside.cpp
/.cu
files. It’s disallowed in headers. -
using namespace std
is disallowed even in.cpp
/.cu
files. If you want to save some work, just typedef the type you need from the std namespace, or useauto
. -
For consistency reasons, use
using
declaration instead oftypedef
e.g., -
Use only sized types (e.g.,
int32_t
,uint32_t
,int16_t
). Conceptually,bool
has unknown size, so no size equivalent.char
is special and can be used only for C strings (useint8_t
otherwise). -
Don’t use
NULL
or 0 to initialize pointers.nullptr
is 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_CRITICAL
for logging. Usingprintf
orstd::cout
is prohibited.NEON_*
logging macro rely onspdlog
with 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
get
andset
-
Functions names that return a
bool
should 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
.h
containing only the class declaration i.e., class name, methods’ signature and variables -
Source file must be a
.cpp
or.cu
and it contains the definition of all methods -
Templated methods definition must be in separate
.h
file 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.,
Grid
class goes intoGrid.h
,Grid.cpp
, andGrid_imp.h
-
The order of public/private members and methods as they appear in the class
.h
file 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.