Summary of High-Quality C++ Programming Guidelines

The core goal of high-quality C++ programming is to write maintainable, scalable, efficient, and safe code. Below are practical high-quality programming guidelines covering key dimensions such as coding standards, design principles, performance optimization, and security practices:

1. Coding Standards and Style

1. Naming Conventions

Variables/Functions: Use snake_case (e.g., user_name, calculate_sum), avoid abbreviations (unless they are widely known abbreviations like id, url).
Classes/Structures: Use PascalCase (e.g., UserInfo, FileHandler), reflecting the concept of “things”.
Constants: Use UPPER_SNAKE_CASE (e.g., MAX_BUFFER_SIZE), to indicate their immutability.
Naming should be “self-explanatory”, avoiding vague names like temp, data (for example, use remaining_bytes instead of left).

2. Code Formatting

Indentation: Use 4 spaces consistently (avoid tabs  , to prevent inconsistent display across platforms).
Braces: The left brace for function/class definitions should be on a new line, while the left brace for conditional/loop statements should follow the statement (e.g., if (x) {).
Blank Lines: Insert blank lines between logical blocks (functions, loops, conditions) to distinguish code levels.
Line Length: Keep within 80-120 characters; long lines should be split (preferably after operators).

3. Commenting Standards

Classes/Functions: Use Doxygen-style comments to describe functionality, parameters, return values, and exceptions (e.g., //<summary>Calculate the sum of two numbers</summary>).
Complex Logic: Comment “why” before code blocks (rather than “what”), such as the key ideas of an algorithm.
Avoid Redundant Comments: Comments like i++ // Increment i reduce readability.

2. Types and Memory Management

1. Prefer Modern C++ Types

Use bool for logical values, avoid using int instead; use size_t for lengths/indices (instead of int, to prevent negative issues).
Use std::string instead of char*, and use STL containers like std::vector/std::map to avoid manual array management.
Use enum class (strongly typed enumeration) to avoid implicit conversions:enum class Color { Red, Green };.

2. Memory Safety

Prohibit raw pointers: Prefer using smart pointers std::unique_ptr (exclusive ownership), std::shared_ptr (shared ownership) to avoid memory leaks and dangling pointers.
Avoid new/delete: Use containers and smart pointers for memory management; when manual management is necessary, ensure new and delete are paired (use delete[] for arrays).
Be cautious of wild pointers: Initialize pointers to nullptr (instead of NULL), to avoid dereferencing uninitialized pointers.

3. Function and Interface Design

1. Function Design Principles

Single Responsibility: A function should do one thing only, with a length of 20-30 lines; if too long, it should be split.
Parameters and Return Values:

Input parameters should use `const&` (e.g., `const std::string& name`), to avoid unnecessary copies.
Output parameters should preferably be passed via return values (e.g., `return std::pair()`), rather than pointers/references (unless necessary).
Avoid too many parameters (recommended not to exceed 4); if too many, encapsulate them in a structure.

Avoid Side Effects: Functions should be as stateless as possible (input determines output), reducing modifications to global variables or external states.

2. Interface Abstraction

Define interfaces using pure virtual functions (class Interface { virtual void func() = 0; };), depending on abstraction rather than concrete implementations (Dependency Inversion Principle).
Interfaces should be stable: Once published, avoid modifying existing method signatures; extensions can be made by adding new interfaces.

4. Object-Oriented Design and Design Patterns

1. Class Design

Encapsulation: Member variables should be set to private, accessed through public methods (getter/setter), hiding internal implementations.
Inheritance: Prefer composition (has-a) over inheritance (is-a); when inheriting, ensure compliance with the “Liskov Substitution Principle” (subclasses can replace parent classes without changing behavior).
Destructors: Base class destructors must be virtual (virtual ~Base() = default;), to avoid memory leaks when deleting subclass objects.

2. Design Patterns

Use patterns appropriately based on the scenario: for example, use Factory Pattern to encapsulate object creation, Observer Pattern for event notification, and Singleton Pattern to manage globally unique resources (with attention to thread safety).
Avoid Over-Design: Do not use patterns just for the sake of using patterns; simple problems should have simple solutions.

5. Performance Optimization

1. Reduce Unnecessary Copies

Use const& to pass large objects, and use move semantics (std::move) to transfer resource ownership (e.g., std::vectorfunc() { …; return std::move(result); }).
Preallocate container space:std::vector calls reserve(n) to avoid performance loss from dynamic resizing.

2. Efficient Use of STL

Prefer range-based for loops for iteration (for (const auto& x : vec) { … }), to avoid out-of-bounds risks.
Algorithm Selection: Use std::find_if instead of handwritten loops, and std::sort is more efficient than custom sorting (STL implementations are optimized).

3. Avoid Premature Optimization

First ensure code correctness and readability, then optimize after identifying performance bottlenecks using profiling tools (e.g., gprof, perf).
Focus on optimizing hot code: loops and frequently called functions should be prioritized, such as reducing memory allocations within loops and merging duplicate calculations.

6. Error Handling and Security

1. Exception Handling

Use exceptions (throw) for rare errors (e.g., file not found), not for expected situations (e.g., user input errors).
Exception Specifications: Clearly specify exceptions that functions may throw (recommended to use noexcept to mark functions that do not throw exceptions after C++17), avoid raw catch(…) (logging is necessary).
RAII Principle: Use object lifetimes to manage resources (e.g., std::lock_guard to manage locks), ensuring resources are correctly released when exceptions occur.

2. Input Validation

Validate all external inputs (user input, network data) to avoid out-of-bounds access, format errors, etc. (e.g., check if std::vector indices are within valid ranges).

3. Thread Safety

Shared data must be locked (std::mutex), or use atomic types (std::atomic).
Avoid deadlocks: Lock in a fixed order, use std::lock to lock multiple locks simultaneously, or set timeouts (std::timed_mutex).

7. Tools and Practices

1. Static Analysis

Use clang-tidy and cppcheck to detect potential issues (e.g., uninitialized variables, memory leaks).
Enable compiler warnings and treat warnings as errors.

2. Testing

Unit Testing: Cover key functions and validate boundary conditions (e.g., empty input, maximum values).
Code Coverage: Ensure core logic is covered by tests.

3. Version Control and Collaboration

Self-review code before submission to ensure compliance with team standards; use git for version management, and commit messages should be clear (e.g., fix: Fix memory leak during user login).

Conclusion

The core of high-quality C++ code is “human-centered”— enabling others who read the code to quickly understand the logic while also considering machine execution efficiency.