00.4 Coding Conventions

Code Repository Conventions

Please make sure to have a look at the official ROS website for more details

• http://wiki.ros.org/BestPractices

README files

Markdown syntax (https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet)

Python

PEP-8 style

ROS Python

REP-8 style

• http://wiki.ros.org/PyStyleGuide
• https://www.python.org/dev/peps/pep-0008/

A quick summary of PEP 8, very similar to ROS C++ above:

• Packages: package_name
• Classes/types:ClassName
• Functions/methods: field_name
• Private Variables: private_something or self.__really_private_field
• Global variables: global
• 4 space indentation

ROS C++:

Google Style (http://wiki.ros.org/CppStyleGuide)

• Files: under_scored, exception for .msg files, CMakeLists.txt
• Classes/types: CamelCase
• Functions/methods: camelCase
• Variables: under_scored and DESCRIPTIVE
• Constants: ALL_CAPITALS
• Global variables: AVOID except special cases. Rather have parameters defined in config.yaml

ROS naming conventions

Thanks to AMZ for the nice overview: We use the naming conventions defined at http://wiki.ros.org/ROS/Patterns/Conventions

Work packages

work_package, lowercase and _ as separator, e.g. lidar.

ROS packages

workpackage_somename, lowercase and _ as separator, e.g. lidar_trimmer, as to make it clear what the package is used for.

ROS nodes

node_name, lowercase and _ as separator. Can be short.

ROS topics

topic_name, lowercase and _ as separator.

ROS messages

CamelCased.msg for message filenames. Message types are always CamelCase, whereas message fields are lowercase and _ as separator, e.g.

MyMessage.msg:
Header header
Float64 my_float
geometry_msgs/Point my_point