move3d

h1. Coding Rules

*Table of Contents*

{{toc}}

An unordered list of stuff we would like devs to follow

h2. Console output and logging

You must use logm3d. std::cout must not appear in any pullrequest. See "the documentation":https://wiki.laas.fr/robots/libmove3d/DeveloperInstructions

h2. Naming

h3. 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)@

h3. 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.

<pre>

struct RobotType{

   enum Value {Robot, Human, Object, NotDefined};

   std::string toString(Value v);

   ...

}

</pre>

h2. 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.

h2. Pull-requests

h3. 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

<pre>

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() {...;...}

</pre>

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.