C++ Programming

1---
2description: 
3globs: **/*.c,**/*.cpp,**/*.h,**/*.hpp,**/*.cxx,CMakeLists.txt,*.cmake,conanfile.txt,Makefile,**/*.cc
4alwaysApply: false
5---
6# C++ Programming Guidelines
7 
8## Basic Principles
9 
10- Use English for all code and documentation.
11- Always declare the type of each variable and function (parameters and return value).
12- Create necessary types and classes.
13- Use Doxygen style comments to document public classes and methods.
14- Don't leave blank lines within a function.
15- Follow the one-definition rule (ODR).
16 
17## Nomenclature
18 
19- Use PascalCase for classes and structures.
20- Use camelCase for variables, functions, and methods.
21- Use ALL_CAPS for constants and macros.
22- Use snake_case for file and directory names.
23- Use UPPERCASE for environment variables.
24- Avoid magic numbers and define constants.
25- Start each function with a verb.
26- Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
27- Use complete words instead of abbreviations and ensure correct spelling.
28  - Except for standard abbreviations like API, URL, etc.
29  - Except for well-known abbreviations:
30    - i, j, k for loops
31    - err for errors
32    - ctx for contexts
33    - req, res for request/response parameters
34 
35## Functions
36 
37- Write short functions with a single purpose. Less than 20 instructions.
38- Name functions with a verb and something else.
39- If it returns a boolean, use isX or hasX, canX, etc.
40- If it doesn't return anything (void), use executeX or saveX, etc.
41- Avoid nesting blocks by:
42  - Early checks and returns.
43  - Extraction to utility functions.
44- Use standard library algorithms (std::for_each, std::transform, std::find, etc.) to avoid function nesting.
45- Use lambda functions for simple operations.
46- Use named functions for non-simple operations.
47- Use default parameter values instead of checking for null or nullptr.
48- Reduce function parameters using structs or classes
49  - Use an object to pass multiple parameters.
50  - Use an object to return multiple results.
51  - Declare necessary types for input arguments and output.
52- Use a single level of abstraction.
53 
54## Data
55 
56- Don't abuse primitive types and encapsulate data in composite types.
57- Avoid data validations in functions and use classes with internal validation.
58- Prefer immutability for data.
59- Use const for data that doesn't change.
60- Use constexpr for compile-time constants.
61- Use std::optional for possibly null values.
62 
63## Classes
64 
65- Follow SOLID principles.
66- Prefer composition over inheritance.
67- Declare interfaces as abstract classes or concepts.
68- Write small classes with a single purpose.
69  - Less than 200 instructions.
70  - Less than 10 public methods.
71  - Less than 10 properties.
72- Use the Rule of Five (or Rule of Zero) for resource management.
73- Make member variables private and provide getters/setters where necessary.
74- Use const-correctness for member functions.
75 
76## Exceptions
77 
78- Use exceptions to handle errors you don't expect.
79- If you catch an exception, it should be to:
80  - Fix an expected problem.
81  - Add context.
82  - Otherwise, use a global handler.
83- Use std::optional, std::expected, or error codes for expected failures.
84 
85## Memory Management
86 
87- Prefer smart pointers (std::unique_ptr, std::shared_ptr) over raw pointers.
88- Use RAII (Resource Acquisition Is Initialization) principles.
89- Avoid memory leaks by proper resource management.
90- Use std::vector and other standard containers instead of C-style arrays.
91 
92## Testing
93 
94- Follow the Arrange-Act-Assert convention for tests.
95- Name test variables clearly.
96- Follow the convention: inputX, mockX, actualX, expectedX, etc.
97- Write unit tests for each public function.
98- Use test doubles to simulate dependencies.
99  - Except for third-party dependencies that are not expensive to execute.
100- Write integration tests for each module.
101- Follow the Given-When-Then convention.
102 
103## Project Structure
104 
105- Use modular architecture
106- Organize code into logical directories:
107  - include/ for header files
108  - src/ for source files
109  - test/ for test files
110  - lib/ for libraries
111  - doc/ for documentation
112- Use CMake or similar build system.
113- Separate interface (.h) from implementation (.cpp).
114- Use namespaces to organize code logically.
115- Create a core namespace for foundational components.
116- Create a utils namespace for utility functions.
117 
118## Standard Library
119 
120- Use the C++ Standard Library whenever possible.
121- Prefer std::string over C-style strings.
122- Use std::vector, std::map, std::unordered_map, etc. for collections.
123- Use std::optional, std::variant, std::any for modern type safety.
124- Use std::filesystem for file operations.
125- Use std::chrono for time-related operations.
126 
127## Concurrency
128 
129- Use std::thread, std::mutex, std::lock_guard for thread safety.
130- Prefer task-based parallelism over thread-based parallelism.
131- Use std::atomic for atomic operations.
132- Avoid data races by proper synchronization.
133- Use thread-safe data structures when necessary.
134 
135