ROS Code Review Guide

Alami · October 9, 2018, 8:17am

We compiled a mini code review guide. The link below

rosin-project/ros_code_review_guide/blob/master/README.md

# ROS Code Review Guide
Code review is having other members of a team critique software changes, and it is important for quality. Traditional code review involved process mandates while modern code review is lightweight and flexible. ROS community adopted a lightweight code review process. This document covers the scope and high-level guideline for ROS code review. 

Code review is not an exact science or prescription. It is a subjective examination of the code to assess its internal quality. During this examination a critical and constructive evaluation of the code occurs. Various aspects of the contribution are evaluated: (1) Purpose, (2) The code adherence to the coding standards and guidelines, (3) Architectural quality of the contribution, (4) Legibility of the code, (5) Maintainability of the code.
### Purpose:
1. Every contribution should have a purpose (i.e. New feature, bug fix, etc.). Does the submitted contribution accomplish a specific purpose? Is this purpose clearly documented?
### Compliance with the coding standards and guidelines:
1. Has the CI coding standards checker been run successfully?
### Architectural quality:
1. Is the proposed solution optimal and architecturally sound for the problem at hand? Think of how you would resolve the problem? 
2. Try to identify shortcuts. Usually shortcuts can compromise quality.
3. Modularity is an important feature to look for. It facilitates maintainability and ease of read. Is the contribution modular?
4. New features fit within the actual architecture.
### Legibility:
1. Is the code readability (the quality of reading and understanding the code) reasonably good? Use your code reading experience to judge the contribution readability. Ask yourself, can I understand what the code does by reading it? (i.e. [Developer Guide](https://github.com/ros2/ros2/wiki/Developer-Guide), [
ROS C++ Style Guide](http://wiki.ros.org/CppStyleGuide#Classes_.2BAC8_Types))
2. Consistency of the code style, naming conventions, but most importantly, consistency in architecture. I.e. Do the names (of fields, variables, parameters, methods and classes) actually reflect the concepts they represent?
3. Is the code sufficiently documented? Do you believe that the code is supported by adequate comments to enhance its readability and understanding? Use your own judgement and experience to assess the comments/code ratio.
### Maintainability:
1.	Is the contribution accompanied with appropriate test cases? Read the tests and check the coverage and the relevance. If there are no test cases, then raise it with the author of the contribution.

This file has been truncated. show original

Any feedback or comments are welcomed.

gbiggs · October 11, 2018, 12:14am

I made a pull request with some changes.

Alami · October 11, 2018, 9:47am

The pull request has been merged. Thanks

Topic		Replies	Views
ROS Quality Assurance Working Group – May 2018 Meetings Minutes Quality Assurance	1	725	May 24, 2018
ROS Quality Assurance Working Group October 2018 Meeting Notes Quality Assurance	1	626	October 17, 2018
ROS Quality Assurance Working Group July 2018 Meeting Notes Quality Assurance	0	639	July 22, 2018
Guidelines on how to architect ROS-based systems Quality Assurance	27	12348	May 9, 2021
ROS Quality Assurance Working Group August 2018 Meeting Notes Quality Assurance	0	514	August 30, 2018

ROS Code Review Guide

Related topics