Coding Rules¶

Table of Contents

• Table of contents
• Coding Rules
  • Console output and logging
  • Naming
    • Classes, attributes, variables
    • Enums
  • Unimplemented stuff
  • Pull-requests
    • History

An unordered list of stuff we would like devs to follow

Console output and logging¶

You must use logm3d. std::cout must not appear in any pullrequest. See the documentation

Naming¶

Classes, attributes, variables¶

• ClassesAreCamelCase with first letter capital, also are all types (typedef, enum, struct,...)
• methodsAreCamelCase with first letter lowercase
• _privateAttributeStartWithUnderscore and is camelCase
• localVariable or local_variable, first letter lowercase
• avoid calling a=function(1.0,6,false,true), declare local variables with descriptive name for the parameters: a=function(step_size,iteration_nb,enable_XYZ,multi_thread)

Enums¶

Put enums in an existing namespace or class, and/or create a struct and put it inside.
That struct can also contain methods to convert to/from string and other types.
Enums and their container struct are CapitalCamelCase, as their values (see example).

Google coding style recommends using MACRO_STYLE for enum values, or constant style, ie. starting with a "k": kRobot. It can be accepted, stay consistent within a "module"/class of move3d.

struct RobotType{
   enum Value {Robot, Human, Object, NotDefined};
   std::string toString(Value v);
   ...
}

Unimplemented stuff¶

• not implemented functions: put an assert(false); in it, it will abort in debug mode, and do nothing in release. (instead of a print or whatever, which is totally unclear)
• but mainly, avoid to commit unimplemented functions.

Pull-requests¶

History¶

Keep the history clean: when a pull-request is made of several commits, something that do not appear in the final state should not appear in any commit. Example:

bad pull-request

commit: A
   creating feature X an Y

diff file.cpp
+ bool funcX() {...}
+ bool funcY() {...}

commit: B
   update in feature X and Y

diff file.cpp
- bool funcX() {...}
- bool funcY() {...}
+ bool funcX() {...;...}
+ bool funcY() {...;...}

commit: C
    remove feature X

diff file.cpp
-bool funcX() {...;...}

The reviewer will review the code of funcX() in commit A, the changes made in commit B, and will be really disappointed when reading commit C. Moreover, it is useless to have such things in the history.