Coding Standards

ROS Standards (REP)

There are way too many to list, so I will just attach the link for ROS REPs. You can use this as a reference, but we strictly go by these standards, to avoid later confusion (i.e Right or Left handed axis)

Tips on the art of coding

These tips are a summary of this ACM article on the art of coding:

• Vertical alignment to show symmetry and tabular structure.
• Naming Conventions
  • Functions that modify their arguments should use verb names.
  • Functions that return values should use noun names.
  • Class names should use collective noun names.
  • Booleans should use adjective names.
  • Try to make names pronouncable
  • Think about how someone reading your code has to infer the concept based on the name (while the person writing the code makes the name based on the concept).
• Rely on context to simplify code. That means shorten names of frequently used variables (so they don't obscure the code), and lengthen names of rarely used variables.
• Use white-space to show structure (kind of like sections and paragraphs in a book or paper)
• Focus on writing clear code, not on writing comments. If you write clear enough code, you won't need too many comments.

C++

Follow the Google Style Guide.

Use cpplint.py available through the guide to lint cpp code.

Python

Follow PEP8 for all python modules submitted to Repo!

You can use utilities like: pep8, flake8, pyflakes to satisfy this criteria

pip install flake8

There are plugins for most major text editors VIM, Sublime Text, etc.

Coding Style

Consistency is the top priority. It doesn't matter what you think is better, what matters most is that the entire team uses a consistent style. Therefore, we should all conform to the official ROS standards here (for C++). For Python, just refer to the PEP8 link.

Here's a summary (or cheat-sheet) that you should use (it's not comprehensive but should be a helpful pointer):

Naming

• The following should be under_scored: packages, topics, files, libraries, and variables (including function arguments).
• Constants should be ALL_CAPITALS.
• Classes should be CamelCased, while functions should be camelCased. (note the first character case)
• Global variable name example: g_my_var (note g_ at beginning)
• Member variable name example: my_var_ (note trailing underscore)

Licenses

Please include a license statement at the beginning of every source code file. Check out the already-existing files in the repo for an example (just copy and paste them over). We use the GNU GPL license. Check out this article for Correctly Licensing.

Formatting

• Indent each block using 2 spaces (don't use tab character).
• Braces go on their own lines.
• Use unsigned int instead of uint for portability.