ros

ros Best Practices

This guide outlines the essential practices for developing robust, performant, and maintainable ROS 2 applications. Adherence to these rules ensures consistency, leverages ROS 2's advanced features, and aligns with the project's quality standards.

1. Code Quality and Static Analysis (The ament Way)

• Mandate ament_lint_auto: Always integrate ament_lint_auto and ament_lint_common into your package build process. This is non-negotiable for catching style violations and common bugs early.

  • ❌ BAD: Relying on manual checks or pre-commit hooks that can be bypassed.
  • ✅ GOOD: Automatic enforcement during every build.

  # CMakeLists.txt
  # ...
  if(BUILD_TESTING)
    find_package(ament_lint_auto REQUIRED)
    ament_lint_auto_find_test_dependencies()
  endif()
  # ...
  

  <!-- package.xml -->
  <package format="2">
    <!-- ... -->
    <test_depend>ament_lint_auto</test_depend>
    <test_depend>ament_lint_common</test_depend>
    <!-- ... -->
  </package>
  

• C++ Style Enforcement: Use ament_cpplint and ament_cppcheck. Follow Google C++ Style Guide and modern C++17/20 features. Prioritize RAII and explicit smart pointer ownership.

  • ❌ BAD: Raw pointers for resource management; ignoring cpplint warnings.
  • ✅ GOOD: std::unique_ptr, std::shared_ptr for ownership.

  // ❌ BAD: Manual memory management, potential leak
  MyObject* obj = new MyObject();
  // ...
  delete obj; // Easy to forget or double-delete
  
  // ✅ GOOD: RAII with smart pointers
  std::unique_ptr<MyObject> obj = std::make_unique<MyObject>();
  // Resource automatically managed
  

• Python Style Enforcement: Adhere strictly to REP-8, which extends PEP 8. Use black for formatting and flake8 for linting. Ensure proper naming, imports, and docstrings.

  • ❌ BAD: Inconsistent formatting, missing docstrings, camelCase for variables.
  • ✅ GOOD: snake_case for variables/functions, clear docstrings, black-formatted code.