Skip to main content

code-style

Code style and naming conventions

In our codes, we try to stick to these naming rules:

File extensions

  • Header files should use the .hpp extension.
    • Rationale: Allow tools to determine content of files, C++ or C.
  • Implementation files should use the .cpp extension.
    • Rationale: Allow tools to determine content of files, C++ or C.

Topics and services snake_case

  • Lowercase with underscores (e.g., laser_scan, planner_state)
  • Descriptive enough to identify purpose without being verbose

ROS Interfaces (Messages, Services, Actions) PascalCase

  • For message files (e.g., LaserScan.msg, YourMessage.msg)
  • Message fields use snake_case lowercase with underscores (e.g., range_min, range_max)

C++ Code

Classes and Structures: PascalCase

  • (e.g., YourNode, YourStruct)

Functions and Methods: camelCase

  • (e.g., getDistance, radiansToDegrees)
Good Practice

Use verbs in infinitive form for functions (e.g., initialize, computePath) and descriptive nouns for classes (e.g., PathPlanner, SensorProcessor).

ROS2 & C++ Style
  • Google style guide says camelCase, but the C++ std library’s style of snake_case is also allowed
  • Rationale: ROS 2 core packages currently use snake_case

Variables: snake_case

  • Lowercase with underscores (e.g., your_variable)

Member variables: snake_case_

  • Lowercase with underscores and trailing underscore (e.g., your_variable_)

Mutexes mutex_snake_case_

  • Lowercase with underscores and mutex_ prefix (e.g., mutex_your_variable_)

ROS Parameters: _snake_case_

  • Lowercase with underscores and _ prefix and suffix (e.g., _your_parameter_)

ROS Interfaces:

  • Lowercase with underscores and prefixes (e.g., sub_your_topic_, pub_your_topic_, server_call_, client_call_, timer_publish_reference_)

MRS Library Handlers: lowercase with underscores and prefixed:

Prefixes indicate the type of handler:

  • Subscribers: sh_
  • Publishers: ph_
  • Service Servers: ss_
  • Service Clients: sc_
  • Timers: timer_
  • Example: sh_laser_scan_, ph_planner_state_, ss_your_server_call_, sc_your_client_call_, timer_publish_reference_

ROS Callback Groups: cbkgrp_snake_case_

  • Lowercase with underscores and cbkgrp_ prefix (e.g., cbkgrp_subs_, cbkgrp_clients_, cbkgrp_servers_, cbkgrp_timers_)

Constants and Defines: SCREAMING_SNAKE_CASE

  • Uppercase with underscores (e.g., YOUR_CONSTANT, YOUR_DEFINE)

Remappings:

  • Subscribers and Servers: lowercase with underscores and _in suffix (e.g., topic_in, service_in)
  • Publishers and Clients: lowercase with underscores and _out suffix (e.g., topic_out, service_out)
Services and Clients rationale

Follow the request direction Example:

  • Service server RECEIVES requests → _in
    • mrs_lib::ServiceServerHandler<> ss_compute_path_;
      • Remapped as: "compute_path_in"
  • Service client SENDS requests → _out
    • mrs_lib::ServiceClientHandler<> sc_compute_path_;
      • Remapped as: "compute_path_out"

This convention makes it clear from the topic/service name whether it's an input or output, as well as giving you possibility to change the topic/service name in the launch file without needing to change the code.

Comments and Doc Comments

Comment from ROS2 Guidelines

  • Use /// and /** */ comments for documentation purposes and // style comments for notes and general comments

  • Class and Function comments should use /// and /** */ style comments

    • Rationale: these are recommended for Doxygen and Sphinx in C/C++

    • Rationale: mixing /* */ and // is convenient for block commenting out code which contains comments

  • Descriptions of how the code works or notes within classes and functions should use // style comments

Some key points:

  • All the names should be descriptive, such that you can deduce their purpose, but not overly long.

  • All the names must be in english. Avoid using uncommon forms or phrases only you understand.

  • Stick to infinitive and basic forms (initialize). Use past or continuous where appropriate (is_initialized, startInitializing).