1---2name: c-programming-guidelines3description: Apply for c-programming-guidelines. --- description: globs: **/*.c,**/*.cpp,**/*.h,**/*.hpp,**/*.cxx,CMakeLists.txt,*.cmake,conanfile.txt,Makefile,**/*.cc4---56# C++ Programming Guidelines78---9description: 10globs: **/*.c,**/*.cpp,**/*.h,**/*.hpp,**/*.cxx,CMakeLists.txt,*.cmake,conanfile.txt,Makefile,**/*.cc11alwaysApply: false12---13# C++ Programming Guidelines1415## Basic Principles1617- Use English for all code and documentation.18- Always declare the type of each variable and function (parameters and return value).19- Create necessary types and classes.20- Use Doxygen style comments to document public classes and methods.21- Don't leave blank lines within a function.22- Follow the one-definition rule (ODR).2324## Nomenclature2526- Use PascalCase for classes and structures.27- Use camelCase for variables, functions, and methods.28- Use ALL_CAPS for constants and macros.29- Use snake_case for file and directory names.30- Use UPPERCASE for environment variables.31- Avoid magic numbers and define constants.32- Start each function with a verb.33- Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.34- Use complete words instead of abbreviations and ensure correct spelling.35 - Except for standard abbreviations like API, URL, etc.36 - Except for well-known abbreviations:37 - i, j, k for loops38 - err for errors39 - ctx for contexts40 - req, res for request/response parameters4142## Functions4344- Write short functions with a single purpose. Less than 20 instructions.45- Name functions with a verb and something else.46- If it returns a boolean, use isX or hasX, canX, etc.47- If it doesn't return anything (void), use executeX or saveX, etc.48- Avoid nesting blocks by:49 - Early checks and returns.50 - Extraction to utility functions.51- Use standard library algorithms (std::for_each, std::transform, std::find, etc.) to avoid function nesting.52- Use lambda functions for simple operations.53- Use named functions for non-simple operations.54- Use default parameter values instead of checking for null or nullptr.55- Reduce function parameters using structs or classes56 - Use an object to pass multiple parameters.57 - Use an object to return multiple results.58 - Declare necessary types for input arguments and output.59- Use a single level of abstraction.6061## Data6263- Don't abuse primitive types and encapsulate data in composite types.64- Avoid data validations in functions and use classes with internal validation.65- Prefer immutability for data.66- Use const for data that doesn't change.67- Use constexpr for compile-time constants.68- Use std::optional for possibly null values.6970## Classes7172- Follow SOLID principles.73- Prefer composition over inheritance.74- Declare interfaces as abstract classes or concepts.75- Write small classes with a single purpose.76 - Less than 200 instructions.77 - Less than 10 public methods.78 - Less than 10 properties.79- Use the Rule of Five (or Rule of Zero) for resource management.80- Make member variables private and provide getters/setters where necessary.81- Use const-correctness for member functions.8283## Exceptions8485- Use exceptions to handle errors you don't expect.86- If you catch an exception, it should be to:87 - Fix an expected problem.88 - Add context.89 - Otherwise, use a global handler.90- Use std::optional, std::expected, or error codes for expected failures.9192## Memory Management9394- Prefer smart pointers (std::unique_ptr, std::shared_ptr) over raw pointers.95- Use RAII (Resource Acquisition Is Initialization) principles.96- Avoid memory leaks by proper resource management.97- Use std::vector and other standard containers instead of C-style arrays.9899## Testing100101- Follow the Arrange-Act-Assert convention for tests.102- Name test variables clearly.103- Follow the convention: inputX, mockX, actualX, expectedX, etc.104- Write unit tests for each public function.105- Use test doubles to simulate dependencies.106 - Except for third-party dependencies that are not expensive to execute.107- Write integration tests for each module.108- Follow the Given-When-Then convention.109110## Project Structure111112- Use modular architecture113- Organize code into logical directories:114 - include/ for header files115 - src/ for source files116 - test/ for test files117 - lib/ for libraries118 - doc/ for documentation119- Use CMake or similar build system.120- Separate interface (.h) from implementation (.cpp).121- Use namespaces to organize code logically.122- Create a core namespace for foundational components.123- Create a utils namespace for utility functions.124125## Standard Library126127- Use the C++ Standard Library whenever possible.128- Prefer std::string over C-style strings.129- Use std::vector, std::map, std::unordered_map, etc. for collections.130- Use std::optional, std::variant, std::any for modern type safety.131- Use std::filesystem for file operations.132- Use std::chrono for time-related operations.133134## Concurrency135136- Use std::thread, std::mutex, std::lock_guard for thread safety.137- Prefer task-based parallelism over thread-based parallelism.138- Use std::atomic for atomic operations.139- Avoid data races by proper synchronization.140- Use thread-safe data structures when necessary.141142