CONTRIBUTING.md

A tool is provided in Revolve (and other repositories) to check for correct style. Your code must have no errors after running the following command from the root of the source tree:

sh tools/code_check.sh

The tool does not catch all style errors. See the Style section below for more information.

Ten Tips for Clean Code

1. You are responsible for the quality of your code
2. When writing code, use meaningful names
3. Write code that expresses the intent
4. Comments are often lies waiting to happen
5. Leave your code better than you found it
6. Single responsibility principle (every method/function should do only one thing)
7. Write tests
8. Work in short cycles: incremental and iterative
9. Independent architecture
10. Practice, practice, practice

Coding Rules

1. Write tests

   A pull request will only be accepted if it has tested. See the Test coverage section below for more information.

2. Compiler warnings

   Code must have zero compile warnings. This currently only applies to Linux.

3. Documentation

   Document all your code. Every class, function, member variable must have Doxygen comments. All code in source files must have documentation that describes the functionality. This will help reviewers and future developers.

4. Small commits

   A large pull request is hard to review and will take a long time. It is worth your time to split a large pull request into multiple smaller pull requests.

Style

1. this pointer

All class attributes and member functions must be accessed using the this-> pointer. Here is an example.

2. Underscore function parameters

All function parameters must start with an underscore. Here is an example.

3. Do not cuddle braces

All braces must be on their own line. Here is an example.

4. Multi-line code blocks

If a block of code spans multiple lines and is part of a flow control statement, such as an if, then it must be wrapped in braces. Here is an example

5. ++ operator

This occurs mostly in for loops. Prefix the ++ operator, which is slightly more efficient than postfix in some cases.

6. PIMPL/Opaque pointer

If you are writing a new class, it must use a private data pointer. Here is an example, and you can read more here.

7. const functions

Any class function that does not change a member variable should be marked as const. Here is an example.

8. const parameters

All parameters that are not modified by a function should be marked as const. This applies to parameters that are passed by reference, pointer, and value. Here is an example.

9. Pointer and reference variables

Place the * and & next to the variable name, not next to the type. For example: int &variable is good, but int& variable is not. Here is an example.

10. Camel case

In general, everything should use camel case. Exceptions include SDF element names, and protobuf variable names. Here is an example.

11. Class function names

Class functions must start with a capital letter, and capitalize every word.

void MyFunction(); : Good

void myFunction(); : Bad

void my_function(); : Bad

12. Variable names

Variables must start with a lower case letter, and capitalize every word thereafter.

int myVariable; : Good

int myvariable; : Bad

int my_variable; : Bad

13. No inline comments

// style comments may not be placed on the same line as code.

speed *= 0.44704; // miles per hour to meters per second : Bad

gazebo-source

git comit message guidelines

The seven rules of a great Git commit message

Keep in mind: This has all been said before.

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

git-source