|
This appendix sets out the basic coding standards and conventions used in Gazebo and libgazebo. Developers are urged to pay attention to these standards, if for no other reason than to avoid annoying other developers.
Gazebo is written in a subset of C++ ("C with classes" as Brian put it recently). This means that use of more advanced C++ "features" (templates, STL, run-time typing, multiple inheritance, etc.) is strongly discouraged.
- Naming Conventions
- C++ header files are suffixed with
.hh, C++ source files are suffixed with .cc; e.g., Model.hh, Model.cc.
- Directory names are lower case, with the exception of model directories, which are camel-capped.
- Coding Conventions
- Class and function names are camel-capped with a leading upper-case character; e.g.
BoxGeom, SetGravity().
- Variable names are camel-capped with a leading lower-case character, and do not include any type encoding (no Hungarian); e.g.
myVariable.
- Class variables and methods are always accessed explicitly: e.g.
this->MyMethod() and this->myVariable.
- Standard indentation is two spaces (no tab characters).
- Matching braces are aligned, e.g.:
if (condition)
{
do_something();
do_something_else();
}
For maximum compatibility and portability, libgazebo is written in C.
- File Naming Conventions
- Source files are lower-case with underscores; e.g.,
gz_laser.c.
- Header files are suffixed with
.h, C source files are suffixed with .c; e.g., gazebo.h, libgazebo.c.
- Source files for interfaces are prefixed by
gz_; e.g., gz_position.c.
- Coding Conventions
- Function names are lower-case with underscores; e.g.,
my_function().
- Variable names are lower-case with underscores, and do not include any type encoding (i.e., no Hungarian); e.g.,
my_variable.
- Standard indentation is two spaces (no tab characters).
- Matching braces are aligned, e.g.:
if (condition)
{
do_something();
do_something_else();
}
|
