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:
The tool does not catch all style errors. See the Style section below for more information.
Ten Tips for Clean Code
- You are responsible for the quality of your code
- When writing code, use meaningful names
- Write code that expresses the intent
- Comments are often lies waiting to happen
- Leave your code better than you found it
- Single responsibility principle (every method/function should do only one thing)
- Write tests
- Work in short cycles: incremental and iterative
- Independent architecture
- Practice, practice, practice
A pull request will only be accepted if it has tested. See the Test coverage section below for more information.
Code must have zero compile warnings. This currently only applies to Linux.
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.
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.
All class attributes and member functions must be accessed using the this-> pointer. Here is an example.
- Underscore function parameters
All function parameters must start with an underscore. Here is an example.
- Do not cuddle braces
All braces must be on their own line. Here is an example.
- 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
This occurs mostly in for loops. Prefix the
++operator, which is slightly more efficient than postfix in some cases.
- 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.
Any class function that does not change a member variable should be marked as
const. Here is an example.
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.
- Pointer and reference variables
&next to the variable name, not next to the type. For example:
int &variableis good, but
int&variable is not. Here is an example.
- Camel case
In general, everything should use camel case. Exceptions include
SDFelement names, and
protobufvariable names. Here is an example.
- 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
- 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
- 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
git comit message guidelines
The seven rules of a great Git commit message
Keep in mind: This has all been said before.
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how