Decide on standard clang-format style about exotica

[VladimirIvan]

I went through the google style guide and PEP8 and further specified the style where there were multiple options. I also added suggestions for package and directory naming convention based off ROS standards.

Packages, files and directories

• Package names in lower case with underscores and exotica prefix:

exotica
exotica_python
exotica_examples
exotica_core_taskmaps
exotica_aico_solver
exotica_ik_solver
exotica_collision_scene_fcl
...

• All solver packages with _solver suffix.
• All task map packages with _taskmaps suffix.
• File names - with_underscores.cpp, with_underscores.h, with_underscores.py (don't use *.cc, *.hpp, ... file types)
• Directory structure:

package_name\
package_name\launch\ (*.launch)
package_name\src\ (*.cpp)
package_name\include\package_name\ (*.h)
package_name\scripts\ (*.py)
package_name\init\ (*.in)
package_name\cmake\ (*.cmake and supporting scripts)
package_name\doc\ (doxygen and other files)
package_name\resources\ (urdf/srdf/meshes/scenes/trajectories/...)
package_name\test\ (c++/python test scripts)
package_name\test\resources\ (test resources)

For files in scripts/, if they are Python file:

• Make the script executable (chmod +x filename)
• Add an appropriate shebang
• Do not include the file ending

C++

• Use override instead of virtual when overriding a function in a child class.

• Order output parameters after inputs if returning values via arguments.

• Avoid boost.

• Always use c++11

• Type names - CamelCasedWithFirstCapitalLetter

• Variable names - with_underscores

• Member variables - with_underscores_and_trailing_underscore_

• Struct data members - with_underscores

• Constants - kCamelCasedWithPrefix

• Function names - CamelCasedWithFirstCapitalLetter

• Namespace names (always single word) - lowercase

• Enum names - CamelCasedWithFirstCapitalLetter

• Enum data members - ALL_CAPS

• Macro names - ALL_CAPS

• Comments - // always use double slash

• File comments - include author, copyright, and license

• File/class/function/variable comments - /// always use doxygen documentation style comments

• Implementation comments - // always use regular double slash comments on a separate line

• TODO - // TODO(githubusername or email) use comments with enough detail - the name references who added it or who is responsible for fixing it

Formatting:

• No line length limit
• Use provided clang-format:
  • Use UTF-8 encoding.
  • Use 4 spaces instead of tabs.
  • Opening { on a new line on the same level as the conditional/function/loop and the closing brace
• Use vertical white space to separate code blocks/declarations.

Python

• Packages/Modules - short lower case (avoid underscores), eg., pyexotica
• Class names - CamelCased
• Function and variable names - lower_case_with_underscores
• Non-public members - _lower_case_with_leading_underscore
• Constants - ALL_CAPS
• Getters/setters - always replace with attributes
• Always include explicit exports (__all__)
• Apply PEP8

[VladimirIvan]

On top of that, we also need to revisit the naming conventions:

• Static/member/local/argument variable names.
• Consistent use of underscores and capitalization.
• Class, struct, enum naming.
• Static/member and public/private function names.

[VladimirIvan]

So here are some proposals:
Formatting:

• Google style - available as CLang format but the curly bracket placement bothers me.
• ROS style - not officially supported and untested CLang, most of the current code uses this format now, I prefer this format.

Naming convention:

• ROS convention.
• ETH convention more detailed, couple of minor differences in capitalization (compared to ROS).

Additional convention for humanoid robots.

[wxmerkt]

I'd opt for clang-format-3.8 Google style. ROS style is not uniform and changing, the CLang isn't really tested. clang-format (and the different versions) is available on all platforms.

Regarding naming convention, no major preference but I'd go with a big standard as well. Not to be 100% strict with that but good to keep as a guideline.

[VladimirIvan]

Formatting fixed in #141.

Todo: fix naming the convention.

[wxmerkt]

C++

• Google C++ Style Guide
• Drake C++ Style Guide
• Drake Robotics Terminology and Notation

Python

• PEP 8