Open
Conversation
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
joaomariolago
suggested changes
Jan 28, 2026
|
|
||
| - Follow the project code style and keep it consistent within each file. | ||
| - Prefer small, focused functions over long procedural blocks. | ||
| - Prefer compile-time checksm add run-time checks for safety-critical paths. |
There was a problem hiding this comment.
Suggested change
| - Prefer compile-time checksm add run-time checks for safety-critical paths. | |
| - Prefer compile-time checks, and add run-time checks only for safety-critical paths. |
| ## Preprocessor rules | ||
|
|
||
| - Only use `#pragma once` and `#include` | ||
| - Do not use `#define` for inline macros or constants, use `inline`, `const`, `constexpr`, or `consteval` instead. |
There was a problem hiding this comment.
This assumes that C++ only code is being used, do we want to broad this for maybe Rust/C?
| - No spaces around `.` or `->`, and no spaces around unary operators. | ||
| - Naming rules follow the project standard. If none is defined, use: | ||
| - `lower_snake_case` for functions and variables | ||
| - `UpperCamel_Case` for classes, structs, enums, and typedefs (e.g., `AP_Compass`) |
There was a problem hiding this comment.
This is not a valid UpperCamelCase (PascalCase); it is a mixture of naming conventions.
Unless dictated by a specific project style, we should avoid this and try to maintain a single, consistent naming convention.
Mixing conventions or having different rules tends to reduce readability and maintainability, as seen in APIs such as OpenGL.
| - `UpperCamel_Case` for classes, structs, enums, and typedefs (e.g., `AP_Compass`) | ||
| - lowercase constants and enumerators | ||
| - uppercase acronyms inside identifiers (e.g., `GCS_MAVLink`) | ||
| - use underscore for private properties |
| ## Class design | ||
|
|
||
| - Use `struct` for plain data, `class` for invariants and encapsulation. | ||
| - Keep data members private, avoid public/protected data in classes. |
There was a problem hiding this comment.
Most of C++ references tends to use member variables/functions to address properties and methods.
Suggested change
| - Keep data members private, avoid public/protected data in classes. | |
| - Keep **member variables** private; avoid use of public or protected **member variables** in C++ classes. |
| ## Header and implementation structure | ||
|
|
||
| - `.h` for headers, `.cpp` for implementations. | ||
| - Headers contain declarations only, no non-const data or function definitions. |
There was a problem hiding this comment.
Suggested change
| - Headers contain declarations only, no non-const data or function definitions. | |
| - Headers should contain declarations only; by default, they must not contain non-const data or function definitions, except for: | |
| - inline functions | |
| - templates | |
| - `constexpr` or `consteval` definitions |
|
|
||
| - `.h` for headers, `.cpp` for implementations. | ||
| - Headers contain declarations only, no non-const data or function definitions. | ||
| - Exceptions: inline functions and templates. |
There was a problem hiding this comment.
Suggested change
| - Exceptions: inline functions and templates. |
Join this with suggestion above
| unless the platform and toolchain explicitly support it and memory costs are measured. | ||
| - Prefer fixed-size arrays, if dynamic containers are needed, use project-approved | ||
| alternatives. | ||
| - Avoid bit fields, use plain booleans. |
There was a problem hiding this comment.
Accordingly to JSF AV Rules [154, 155, 156]
Suggested change
| - Avoid bit fields, use plain booleans. | |
| - Avoid using bit-fields for data packing or space optimization. | |
| - For general state and control logic, prefer plain boolean or integer members over bit-fields. | |
| - Bit-fields may be used only when required for hardware register mapping or protocol conformance, and shall use explicitly unsigned integral or enumeration types. | |
| - Do not rely on implementation-defined bit-field behavior. |
|
|
||
| ## Style and naming | ||
|
|
||
| - Avoid tabs, indent consistently (use 2 or four spaces, be consistent with the project). |
There was a problem hiding this comment.
Suggested change
| - Avoid tabs, indent consistently (use 2 or four spaces, be consistent with the project). | |
| - Avoid tabs; use spaces for indentation. The exact width (2 or 4 spaces) must follow the project standard and remain consistent within a file. |
| - Do not call virtual functions from constructors or destructors. | ||
| - Use member initializer lists for non-static members. | ||
| - Declare copy/assignment when owning pointers or nontrivial destructors. | ||
| - Base classes with virtual functions must have virtual destructors. |
There was a problem hiding this comment.
Suggested change
| - Base classes with virtual functions must have virtual destructors. | |
| - Base classes with virtual functions must have virtual destructors, unless the class is | |
| explicitly marked as `final`. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.