现代C++编码标准指南：C++17/20/23核心准则与最佳实践

cpp-coding-standards by affaan-m/everything-claude-code

1,200 周安装量

108,100 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/affaan-m/everything-claude-code --skill cpp-coding-standards

开发

🇨🇳中文介绍

C++ 编码标准（C++ 核心准则）

源自 C++ Core Guidelines 的现代 C++（C++17/20/23）综合编码标准。强制执行类型安全、资源安全、不变性和清晰性。

使用时机

编写新的 C++ 代码（类、函数、模板）
审查或重构现有的 C++ 代码
在 C++ 项目中做出架构决策
在 C++ 代码库中强制执行一致的风格
在语言特性之间做出选择（例如，enum 与 enum class，原始指针与智能指针）

不适用时机

非 C++ 项目
无法采用现代 C++ 特性的遗留 C 代码库
特定准则与硬件约束冲突的嵌入式/裸机环境（选择性采用）

贯穿性原则

这些主题在整个准则中反复出现并构成基础：

处处使用 RAII（P.8, R.1, E.6, CP.20）：将资源生命周期绑定到对象生命周期
默认不可变（P.10, Con.1-5, ES.25）：从 const/constexpr 开始；可变性是例外
类型安全（P.4, I.4, ES.46-49, Enum.3）：使用类型系统在编译时防止错误
（P.3, F.1, NL.1-2, T.10）：名称、类型和概念应传达目的

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

哲学与接口（P., I.）

规则	摘要
P.1	直接在代码中表达想法
P.3	表达意图
P.4	理想情况下，程序应该是静态类型安全的
P.5	优先编译时检查而非运行时检查
P.8	不要泄漏任何资源
P.10	优先使用不可变数据而非可变数据
I.1	使接口明确
I.2	避免非常量全局变量
I.4	使接口精确且强类型化
I.11	永远不要通过原始指针或引用转移所有权
I.23	保持函数参数数量较少

// P.10 + I.4: 不可变的强类型接口
struct Temperature {
    double kelvin;
};

Temperature boil(const Temperature& water);

// 弱接口：所有权不明确，单位不明确
double boil(double* temp);

// 非常量全局变量
int g_counter = 0;  // 违反 I.2

规则	摘要
F.1	将有意义的操作打包为精心命名的函数
F.2	一个函数应执行单一逻辑操作
F.3	保持函数简短简单
F.4	如果函数可能在编译时求值，将其声明为 `constexpr`
F.6	如果你的函数必须不抛出异常，将其声明为 `noexcept`
F.8	优先使用纯函数
F.16	对于“输入”参数，廉价可复制的类型按值传递，其他按 `const&` 传递
F.20	对于“输出”值，优先返回值而非输出参数
F.21	要返回多个“输出”值，优先返回结构体
F.43	永远不要返回指向局部对象的指针或引用

// F.16: 廉价类型按值传递，其他按 const& 传递
void print(int x);                           // 廉价：按值传递
void analyze(const std::string& data);       // 昂贵：按 const& 传递
void transform(std::string s);               // 接收器：按值传递（将移动）

// F.20 + F.21: 返回值，而非输出参数
struct ParseResult {
    std::string token;
    int position;
};

ParseResult parse(std::string_view input);   // 良好：返回结构体

// 不良：输出参数
void parse(std::string_view input,
           std::string& token, int& pos);    // 避免这样做

纯函数和 constexpr

// F.4 + F.8: 纯函数，尽可能使用 constexpr
constexpr int factorial(int n) noexcept {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}

static_assert(factorial(5) == 120);

从函数返回 T&&（F.45）
使用 va_arg / C 风格可变参数（F.55）
在传递给其他线程的 lambda 中通过引用捕获（F.53）
返回 const T 会抑制移动语义（F.49）

类与类层次结构（C.*）

规则	摘要
C.2	如果存在不变量，使用 `class`；如果数据成员独立变化，使用 `struct`
C.9	最小化成员的暴露
C.20	如果可以避免定义默认操作，就避免（零法则）
C.21	如果你定义或 `=delete` 任何复制/移动/析构函数，处理所有相关函数（五法则）
C.35	基类析构函数：公开虚函数或受保护非虚函数
C.41	构造函数应创建完全初始化的对象
C.46	将单参数构造函数声明为 `explicit`
C.67	多态类应抑制公开复制/移动
C.128	虚函数：明确指定 `virtual`、`override` 或 `final` 中的一个

// C.20: 让编译器生成特殊成员
struct Employee {
    std::string name;
    std::string department;
    int id;
    // 不需要析构函数、复制/移动构造函数或赋值运算符
};

// C.21: 如果必须管理资源，定义全部五个
class Buffer {
public:
    explicit Buffer(std::size_t size)
        : data_(std::make_unique<char[]>(size)), size_(size) {}

    ~Buffer() = default;

    Buffer(const Buffer& other)
        : data_(std::make_unique<char[]>(other.size_)), size_(other.size_) {
        std::copy_n(other.data_.get(), size_, data_.get());
    }

    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            auto new_data = std::make_unique<char[]>(other.size_);
            std::copy_n(other.data_.get(), other.size_, new_data.get());
            data_ = std::move(new_data);
            size_ = other.size_;
        }
        return *this;
    }

    Buffer(Buffer&&) noexcept = default;
    Buffer& operator=(Buffer&&) noexcept = default;

private:
    std::unique_ptr<char[]> data_;
    std::size_t size_;
};

// C.35 + C.128: 虚析构函数，使用 override
class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;  // C.121: 纯接口
};

class Circle : public Shape {
public:
    explicit Circle(double r) : radius_(r) {}
    double area() const override { return 3.14159 * radius_ * radius_; }

private:
    double radius_;
};

在构造函数/析构函数中调用虚函数（C.82）
对非平凡类型使用 memset/memcpy（C.90）
为虚函数和覆盖函数提供不同的默认参数（C.140）
将数据成员设为 const 或引用，这会抑制移动/复制（C.12）

资源管理（R.*）

规则	摘要
R.1	使用 RAII 自动管理资源
R.3	原始指针（`T*`）是非拥有的
R.5	优先使用作用域对象；不要不必要地在堆上分配
R.10	避免 `malloc()`/`free()`
R.11	避免显式调用 `new` 和 `delete`
R.20	使用 `unique_ptr` 或 `shared_ptr` 表示所有权
R.21	除非共享所有权，否则优先使用 `unique_ptr` 而非 `shared_ptr`
R.22	使用 `make_shared()` 创建 `shared_ptr`

// R.11 + R.20 + R.21: 使用智能指针的 RAII
auto widget = std::make_unique<Widget>("config");  // 唯一所有权
auto cache  = std::make_shared<Cache>(1024);        // 共享所有权

// R.3: 原始指针 = 非拥有观察者
void render(const Widget* w) {  // 不拥有 w
    if (w) w->draw();
}

render(widget.get());

// R.1: 资源获取即初始化
class FileHandle {
public:
    explicit FileHandle(const std::string& path)
        : handle_(std::fopen(path.c_str(), "r")) {
        if (!handle_) throw std::runtime_error("Failed to open: " + path);
    }

    ~FileHandle() {
        if (handle_) std::fclose(handle_);
    }

    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
    FileHandle(FileHandle&& other) noexcept
        : handle_(std::exchange(other.handle_, nullptr)) {}
    FileHandle& operator=(FileHandle&& other) noexcept {
        if (this != &other) {
            if (handle_) std::fclose(handle_);
            handle_ = std::exchange(other.handle_, nullptr);
        }
        return *this;
    }

private:
    std::FILE* handle_;
};

裸露的 new/delete（R.11）
C++ 代码中的 malloc()/free()（R.10）
在单个表达式中进行多次资源分配（R.13 —— 异常安全风险）
在 unique_ptr 足够时使用 shared_ptr（R.21）

表达式与语句（ES.*）

规则	摘要
ES.5	保持作用域小
ES.20	始终初始化对象
ES.23	优先使用 `{}` 初始化语法
ES.25	除非打算修改，否则将对象声明为 `const` 或 `constexpr`
ES.28	使用 lambda 进行 `const` 变量的复杂初始化
ES.45	避免魔法常量；使用符号常量
ES.46	避免窄化/有损算术转换
ES.47	使用 `nullptr` 而非 `0` 或 `NULL`
ES.48	避免强制转换
ES.50	不要强制转换掉 `const`

// ES.20 + ES.23 + ES.25: 始终初始化，优先使用 {}，默认为 const
const int max_retries{3};
const std::string name{"widget"};
const std::vector<int> primes{2, 3, 5, 7, 11};

// ES.28: 使用 lambda 进行复杂的 const 初始化
const auto config = [&] {
    Config c;
    c.timeout = std::chrono::seconds{30};
    c.retries = max_retries;
    c.verbose = debug_mode;
    return c;
}();

未初始化的变量（ES.20）
使用 0 或 NULL 作为指针（ES.47 —— 使用 nullptr）
C 风格强制转换（ES.48 —— 使用 static_cast、const_cast 等）
强制转换掉 const（ES.50）
没有命名常量的魔法数字（ES.45）
混合有符号和无符号算术运算（ES.100）
在嵌套作用域中重用名称（ES.12）

错误处理（E.*）

规则	摘要
E.1	在设计早期制定错误处理策略
E.2	抛出异常以表示函数无法执行其分配的任务
E.6	使用 RAII 防止泄漏
E.12	当抛出异常不可能或不可接受时，使用 `noexcept`
E.14	使用专门设计的用户定义类型作为异常
E.15	按值抛出，按引用捕获
E.16	析构函数、释放和交换绝不能失败
E.17	不要试图在每个函数中捕获每个异常

// E.14 + E.15: 自定义异常类型，按值抛出，按引用捕获
class AppError : public std::runtime_error {
public:
    using std::runtime_error::runtime_error;
};

class NetworkError : public AppError {
public:
    NetworkError(const std::string& msg, int code)
        : AppError(msg), status_code(code) {}
    int status_code;
};

void fetch_data(const std::string& url) {
    // E.2: 抛出以表示失败
    throw NetworkError("connection refused", 503);
}

void run() {
    try {
        fetch_data("https://api.example.com");
    } catch (const NetworkError& e) {
        log_error(e.what(), e.status_code);
    } catch (const AppError& e) {
        log_error(e.what());
    }
    // E.17: 不要在这里捕获所有异常 —— 让意外错误传播
}

抛出内置类型，如 int 或字符串字面量（E.14）
按值捕获（切片风险）（E.15）
静默吞没错误的空 catch 块
使用异常进行流程控制（E.3）
基于全局状态（如 errno）的错误处理（E.28）

常量与不变性（Con.*）

规则	摘要
Con.1	默认情况下，使对象不可变
Con.2	默认情况下，使成员函数为 `const`
Con.3	默认情况下，传递指向 `const` 的指针和引用
Con.4	对于构造后不变的值，使用 `const`
Con.5	对于可在编译时计算的值，使用 `constexpr`

// Con.1 到 Con.5: 默认不可变性
class Sensor {
public:
    explicit Sensor(std::string id) : id_(std::move(id)) {}

    // Con.2: 默认情况下为 const 成员函数
    const std::string& id() const { return id_; }
    double last_reading() const { return reading_; }

    // 仅当需要修改时才为非 const
    void record(double value) { reading_ = value; }

private:
    const std::string id_;  // Con.4: 构造后永不改变
    double reading_{0.0};
};

// Con.3: 通过 const 引用传递
void display(const Sensor& s) {
    std::cout << s.id() << ": " << s.last_reading() << '\n';
}

// Con.5: 编译时常量
constexpr double PI = 3.14159265358979;
constexpr int MAX_SENSORS = 256;

并发与并行（CP.*）

规则	摘要
CP.2	避免数据竞争
CP.3	最小化可写数据的显式共享
CP.4	从任务角度思考，而非线程
CP.8	不要使用 `volatile` 进行同步
CP.20	使用 RAII，永远不要使用普通的 `lock()`/`unlock()`
CP.21	使用 `std::scoped_lock` 获取多个互斥锁
CP.22	持有锁时永远不要调用未知代码
CP.42	不要在没有条件的情况下等待
CP.44	记得为你的 `lock_guard` 和 `unique_lock` 命名
CP.100	除非绝对必要，否则不要使用无锁编程

// CP.20 + CP.44: RAII 锁，始终命名
class ThreadSafeQueue {
public:
    void push(int value) {
        std::lock_guard<std::mutex> lock(mutex_);  // CP.44: 已命名！
        queue_.push(value);
        cv_.notify_one();
    }

    int pop() {
        std::unique_lock<std::mutex> lock(mutex_);
        // CP.42: 始终在条件下等待
        cv_.wait(lock, [this] { return !queue_.empty(); });
        const int value = queue_.front();
        queue_.pop();
        return value;
    }

private:
    std::mutex mutex_;             // CP.50: 互斥锁与其数据在一起
    std::condition_variable cv_;
    std::queue<int> queue_;
};

// CP.21: 使用 std::scoped_lock 处理多个互斥锁（无死锁）
void transfer(Account& from, Account& to, double amount) {
    std::scoped_lock lock(from.mutex_, to.mutex_);
    from.balance_ -= amount;
    to.balance_ += amount;
}

使用 volatile 进行同步（CP.8 —— 仅用于硬件 I/O）
分离线程（CP.26 —— 生命周期管理变得几乎不可能）
未命名的锁保护：std::lock_guard<std::mutex>(m); 会立即销毁（CP.44）
持有锁时调用回调函数（CP.22 —— 死锁风险）
没有深厚专业知识的情况下进行无锁编程（CP.100）

模板与泛型编程（T.*）

规则	摘要
T.1	使用模板提高抽象层次
T.2	使用模板表达适用于多种参数类型的算法
T.10	为所有模板参数指定概念
T.11	尽可能使用标准概念
T.13	对于简单概念，优先使用简写表示法
T.43	优先使用 `using` 而非 `typedef`
T.120	仅当真正需要时才使用模板元编程
T.144	不要特化函数模板（改为重载）

#include <concepts>

// T.10 + T.11: 使用标准概念约束模板
template<std::integral T>
T gcd(T a, T b) {
    while (b != 0) {
        a = std::exchange(b, a % b);
    }
    return a;
}

// T.13: 简写概念语法
void sort(std::ranges::random_access_range auto& range) {
    std::ranges::sort(range);
}

// 用于领域特定约束的自定义概念
template<typename T>
concept Serializable = requires(const T& t) {
    { t.serialize() } -> std::convertible_to<std::string>;
};

template<Serializable T>
void save(const T& obj, const std::string& path);

在可见命名空间中使用无约束模板（T.47）
特化函数模板而非重载（T.144）
在 constexpr 足够时使用模板元编程（T.120）
使用 typedef 而非 using（T.43）

规则	摘要
SL.1	尽可能使用库
SL.2	优先使用标准库而非其他库
SL.con.1	优先使用 `std::array` 或 `std::vector` 而非 C 数组
SL.con.2	默认优先使用 `std::vector`
SL.str.1	使用 `std::string` 拥有字符序列
SL.str.2	使用 `std::string_view` 引用字符序列
SL.io.50	避免使用 `endl`（使用 `'\n'` —— `endl` 会强制刷新）

// SL.con.1 + SL.con.2: 优先使用 vector/array 而非 C 数组
const std::array<int, 4> fixed_data{1, 2, 3, 4};
std::vector<std::string> dynamic_data;

// SL.str.1 + SL.str.2: string 拥有，string_view 观察
std::string build_greeting(std::string_view name) {
    return "Hello, " + std::string(name) + "!";
}

// SL.io.50: 使用 '\n' 而非 endl
std::cout << "result: " << value << '\n';

规则	摘要
Enum.1	优先使用枚举而非宏
Enum.3	优先使用 `enum class` 而非普通 `enum`
Enum.5	不要对枚举项使用 ALL_CAPS
Enum.6	避免未命名的枚举

// Enum.3 + Enum.5: 作用域枚举，不使用 ALL_CAPS
enum class Color { red, green, blue };
enum class LogLevel { debug, info, warning, error };

// 不良：普通枚举泄漏名称，ALL_CAPS 与宏冲突
enum { RED, GREEN, BLUE };           // 违反 Enum.3 + Enum.5 + Enum.6
#define MAX_SIZE 100                  // 违反 Enum.1 —— 使用 constexpr

源文件与命名（SF., NL.）

规则	摘要
SF.1	使用 `.cpp` 作为代码文件，`.h` 作为接口文件
SF.7	不要在头文件的全局作用域中编写 `using namespace`
SF.8	对所有 `.h` 文件使用 `#include` 防护
SF.11	头文件应自包含
NL.5	避免在名称中编码类型信息（不要使用匈牙利命名法）
NL.8	使用一致的命名风格
NL.9	仅对宏名称使用 ALL_CAPS
NL.10	优先使用 `underscore_style` 命名

// SF.8: 包含防护（或 #pragma once）
#ifndef PROJECT_MODULE_WIDGET_H
#define PROJECT_MODULE_WIDGET_H

// SF.11: 自包含 —— 包含此头文件所需的一切
#include <string>
#include <vector>

namespace project::module {

class Widget {
public:
    explicit Widget(std::string name);
    const std::string& name() const;

private:
    std::string name_;
};

}  // namespace project::module

#endif  // PROJECT_MODULE_WIDGET_H

// NL.8 + NL.10: 一致的 underscore_style
namespace my_project {

constexpr int max_buffer_size = 4096;  // NL.9: 不是 ALL_CAPS（它不是宏）

class tcp_connection {                 // underscore_style 类
public:
    void send_message(std::string_view msg);
    bool is_connected() const;

private:
    std::string host_;                 // 成员使用尾随下划线
    int port_;
};

}  // namespace my_project

在头文件的全局作用域中使用 using namespace std;（SF.7）
依赖包含顺序的头文件（SF.10, SF.11）
匈牙利命名法，如 strName、iCount（NL.5）
对宏以外的任何东西使用 ALL_CAPS（NL.9）

规则	摘要
Per.1	没有理由不要优化
Per.2	不要过早优化
Per.6	没有测量不要对性能做出断言
Per.7	设计以支持优化
Per.10	依赖静态类型系统
Per.11	将计算从运行时移至编译时
Per.19	以可预测的方式访问内存

// Per.11: 尽可能在编译时计算
constexpr auto lookup_table = [] {
    std::array<int, 256> table{};
    for (int i = 0; i < 256; ++i) {
        table[i] = i * i;
    }
    return table;
}();

// Per.19: 优先使用连续数据以提高缓存友好性
std::vector<Point> points;           // 良好：连续
std::vector<std::unique_ptr<Point>> indirect_points; // 不良：指针追逐

没有性能分析数据就进行优化（Per.1, Per.6）
选择“聪明”的低级代码而非清晰的抽象（Per.4, Per.5）
忽略数据布局和缓存行为（Per.19）

快速参考检查清单

在标记 C++ 工作完成之前：

没有裸露的 new/delete —— 使用智能指针或 RAII（R.11）
对象在声明时初始化（ES.20）
变量默认为 const/constexpr（Con.1, ES.25）
成员函数尽可能为 const（Con.2）
使用 enum class 而非普通 enum（Enum.3）
使用 nullptr 而非 0/NULL（ES.47）
没有窄化转换（ES.46）
没有 C 风格强制转换（ES.48）
单参数构造函数为 explicit（C.46）
应用了零法则或五法则（C.20, C.21）
基类析构函数为公开虚函数或受保护非虚函数（C.35）
模板使用概念约束（T.10）
头文件的全局作用域中没有 using namespace（SF.7）
头文件有包含防护且自包含（SF.8, SF.11）
锁使用 RAII（scoped_lock/lock_guard）（CP.20）
异常是自定义类型，按值抛出，按引用捕获（E.14, E.15）
使用 '\n' 而非 std::endl（SL.io.50）
没有魔法数字（ES.45）

🇺🇸English

C++ Coding Standards (C++ Core Guidelines)

Comprehensive coding standards for modern C++ (C++17/20/23) derived from the C++ Core Guidelines. Enforces type safety, resource safety, immutability, and clarity.

When to Use

Writing new C++ code (classes, functions, templates)
Reviewing or refactoring existing C++ code
Making architectural decisions in C++ projects
Enforcing consistent style across a C++ codebase
Choosing between language features (e.g., enum vs enum class, raw pointer vs smart pointer)

When NOT to Use

Non-C++ projects
Legacy C codebases that cannot adopt modern C++ features
Embedded/bare-metal contexts where specific guidelines conflict with hardware constraints (adapt selectively)

Cross-Cutting Principles

These themes recur across the entire guidelines and form the foundation:

RAII everywhere (P.8, R.1, E.6, CP.20): Bind resource lifetime to object lifetime
Immutability by default (P.10, Con.1-5, ES.25): Start with const/constexpr; mutability is the exception
Type safety (P.4, I.4, ES.46-49, Enum.3): Use the type system to prevent errors at compile time
Express intent (P.3, F.1, NL.1-2, T.10): Names, types, and concepts should communicate purpose
Minimize complexity (F.2-3, ES.5, Per.4-5): Simple code is correct code
Value semantics over pointer semantics (C.10, R.3-5, F.20, CP.31): Prefer returning by value and scoped objects

Philosophy & Interfaces (P., I.)

Key Rules

Rule	Summary
P.1	Express ideas directly in code
P.3	Express intent
P.4	Ideally, a program should be statically type safe
P.5	Prefer compile-time checking to run-time checking
P.8	Don't leak any resources
P.10	Prefer immutable data to mutable data
I.1	Make interfaces explicit
I.2	Avoid non-const global variables
I.4	Make interfaces precisely and strongly typed
I.11	Never transfer ownership by a raw pointer or reference

DO

// P.10 + I.4: Immutable, strongly typed interface
struct Temperature {
    double kelvin;
};

Temperature boil(const Temperature& water);

DON'T

// Weak interface: unclear ownership, unclear units
double boil(double* temp);

// Non-const global variable
int g_counter = 0;  // I.2 violation

Functions (F.*)

Key Rules

Rule	Summary
F.1	Package meaningful operations as carefully named functions
F.2	A function should perform a single logical operation
F.3	Keep functions short and simple
F.4	If a function might be evaluated at compile time, declare it `constexpr`
F.6	If your function must not throw, declare it `noexcept`
F.8	Prefer pure functions
F.16	For "in" parameters, pass cheaply-copied types by value and others by `const&`

Parameter Passing

// F.16: Cheap types by value, others by const&
void print(int x);                           // cheap: by value
void analyze(const std::string& data);       // expensive: by const&
void transform(std::string s);               // sink: by value (will move)

// F.20 + F.21: Return values, not output parameters
struct ParseResult {
    std::string token;
    int position;
};

ParseResult parse(std::string_view input);   // GOOD: return struct

// BAD: output parameters
void parse(std::string_view input,
           std::string& token, int& pos);    // avoid this

Pure Functions and constexpr

// F.4 + F.8: Pure, constexpr where possible
constexpr int factorial(int n) noexcept {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}

static_assert(factorial(5) == 120);

Anti-Patterns

Returning T&& from functions (F.45)
Using va_arg / C-style variadics (F.55)
Capturing by reference in lambdas passed to other threads (F.53)
Returning const T which inhibits move semantics (F.49)

Classes & Class Hierarchies (C.*)

Key Rules

Rule	Summary
C.2	Use `class` if invariant exists; `struct` if data members vary independently
C.9	Minimize exposure of members
C.20	If you can avoid defining default operations, do (Rule of Zero)
C.21	If you define or `=delete` any copy/move/destructor, handle them all (Rule of Five)
C.35	Base class destructor: public virtual or protected non-virtual
C.41	A constructor should create a fully initialized object
C.46	Declare single-argument constructors

Rule of Zero

// C.20: Let the compiler generate special members
struct Employee {
    std::string name;
    std::string department;
    int id;
    // No destructor, copy/move constructors, or assignment operators needed
};

Rule of Five

// C.21: If you must manage a resource, define all five
class Buffer {
public:
    explicit Buffer(std::size_t size)
        : data_(std::make_unique<char[]>(size)), size_(size) {}

    ~Buffer() = default;

    Buffer(const Buffer& other)
        : data_(std::make_unique<char[]>(other.size_)), size_(other.size_) {
        std::copy_n(other.data_.get(), size_, data_.get());
    }

    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            auto new_data = std::make_unique<char[]>(other.size_);
            std::copy_n(other.data_.get(), other.size_, new_data.get());
            data_ = std::move(new_data);
            size_ = other.size_;
        }
        return *this;
    }

    Buffer(Buffer&&) noexcept = default;
    Buffer& operator=(Buffer&&) noexcept = default;

private:
    std::unique_ptr<char[]> data_;
    std::size_t size_;
};

Class Hierarchy

// C.35 + C.128: Virtual destructor, use override
class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;  // C.121: pure interface
};

class Circle : public Shape {
public:
    explicit Circle(double r) : radius_(r) {}
    double area() const override { return 3.14159 * radius_ * radius_; }

private:
    double radius_;
};

Anti-Patterns

Calling virtual functions in constructors/destructors (C.82)
Using memset/memcpy on non-trivial types (C.90)
Providing different default arguments for virtual function and overrider (C.140)
Making data members const or references, which suppresses move/copy (C.12)

Resource Management (R.*)

Key Rules

Rule	Summary
R.1	Manage resources automatically using RAII
R.3	A raw pointer (`T*`) is non-owning
R.5	Prefer scoped objects; don't heap-allocate unnecessarily
R.10	Avoid `malloc()`/`free()`
R.11	Avoid calling `new` and `delete` explicitly
R.20

Smart Pointer Usage

// R.11 + R.20 + R.21: RAII with smart pointers
auto widget = std::make_unique<Widget>("config");  // unique ownership
auto cache  = std::make_shared<Cache>(1024);        // shared ownership

// R.3: Raw pointer = non-owning observer
void render(const Widget* w) {  // does NOT own w
    if (w) w->draw();
}

render(widget.get());

RAII Pattern

// R.1: Resource acquisition is initialization
class FileHandle {
public:
    explicit FileHandle(const std::string& path)
        : handle_(std::fopen(path.c_str(), "r")) {
        if (!handle_) throw std::runtime_error("Failed to open: " + path);
    }

    ~FileHandle() {
        if (handle_) std::fclose(handle_);
    }

    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
    FileHandle(FileHandle&& other) noexcept
        : handle_(std::exchange(other.handle_, nullptr)) {}
    FileHandle& operator=(FileHandle&& other) noexcept {
        if (this != &other) {
            if (handle_) std::fclose(handle_);
            handle_ = std::exchange(other.handle_, nullptr);
        }
        return *this;
    }

private:
    std::FILE* handle_;
};

Anti-Patterns

Naked new/delete (R.11)
malloc()/free() in C++ code (R.10)
Multiple resource allocations in a single expression (R.13 -- exception safety hazard)
shared_ptr where unique_ptr suffices (R.21)

Expressions & Statements (ES.*)

Key Rules

Rule	Summary
ES.5	Keep scopes small
ES.20	Always initialize an object
ES.23	Prefer `{}` initializer syntax
ES.25	Declare objects `const` or `constexpr` unless modification is intended
ES.28	Use lambdas for complex initialization of `const` variables
ES.45	Avoid magic constants; use symbolic constants

Initialization

// ES.20 + ES.23 + ES.25: Always initialize, prefer {}, default to const
const int max_retries{3};
const std::string name{"widget"};
const std::vector<int> primes{2, 3, 5, 7, 11};

// ES.28: Lambda for complex const initialization
const auto config = [&] {
    Config c;
    c.timeout = std::chrono::seconds{30};
    c.retries = max_retries;
    c.verbose = debug_mode;
    return c;
}();

Anti-Patterns

Uninitialized variables (ES.20)
Using 0 or NULL as pointer (ES.47 -- use nullptr)
C-style casts (ES.48 -- use static_cast, const_cast, etc.)
Casting away const (ES.50)
Magic numbers without named constants (ES.45)
Mixing signed and unsigned arithmetic (ES.100)
Reusing names in nested scopes (ES.12)

Error Handling (E.*)

Key Rules

Rule	Summary
E.1	Develop an error-handling strategy early in a design
E.2	Throw an exception to signal that a function can't perform its assigned task
E.6	Use RAII to prevent leaks
E.12	Use `noexcept` when throwing is impossible or unacceptable
E.14	Use purpose-designed user-defined types as exceptions
E.15	Throw by value, catch by reference
E.16	Destructors, deallocation, and swap must never fail
E.17	Don't try to catch every exception in every function

Exception Hierarchy

// E.14 + E.15: Custom exception types, throw by value, catch by reference
class AppError : public std::runtime_error {
public:
    using std::runtime_error::runtime_error;
};

class NetworkError : public AppError {
public:
    NetworkError(const std::string& msg, int code)
        : AppError(msg), status_code(code) {}
    int status_code;
};

void fetch_data(const std::string& url) {
    // E.2: Throw to signal failure
    throw NetworkError("connection refused", 503);
}

void run() {
    try {
        fetch_data("https://api.example.com");
    } catch (const NetworkError& e) {
        log_error(e.what(), e.status_code);
    } catch (const AppError& e) {
        log_error(e.what());
    }
    // E.17: Don't catch everything here -- let unexpected errors propagate
}

Anti-Patterns

Throwing built-in types like int or string literals (E.14)
Catching by value (slicing risk) (E.15)
Empty catch blocks that silently swallow errors
Using exceptions for flow control (E.3)
Error handling based on global state like errno (E.28)

Constants & Immutability (Con.*)

All Rules

Rule	Summary
Con.1	By default, make objects immutable
Con.2	By default, make member functions `const`
Con.3	By default, pass pointers and references to `const`
Con.4	Use `const` for values that don't change after construction
Con.5	Use `constexpr` for values computable at compile time

// Con.1 through Con.5: Immutability by default
class Sensor {
public:
    explicit Sensor(std::string id) : id_(std::move(id)) {}

    // Con.2: const member functions by default
    const std::string& id() const { return id_; }
    double last_reading() const { return reading_; }

    // Only non-const when mutation is required
    void record(double value) { reading_ = value; }

private:
    const std::string id_;  // Con.4: never changes after construction
    double reading_{0.0};
};

// Con.3: Pass by const reference
void display(const Sensor& s) {
    std::cout << s.id() << ": " << s.last_reading() << '\n';
}

// Con.5: Compile-time constants
constexpr double PI = 3.14159265358979;
constexpr int MAX_SENSORS = 256;

Concurrency & Parallelism (CP.*)

Key Rules

Rule	Summary
CP.2	Avoid data races
CP.3	Minimize explicit sharing of writable data
CP.4	Think in terms of tasks, rather than threads
CP.8	Don't use `volatile` for synchronization
CP.20	Use RAII, never plain `lock()`/`unlock()`
CP.21	Use `std::scoped_lock` to acquire multiple mutexes

Safe Locking

// CP.20 + CP.44: RAII locks, always named
class ThreadSafeQueue {
public:
    void push(int value) {
        std::lock_guard<std::mutex> lock(mutex_);  // CP.44: named!
        queue_.push(value);
        cv_.notify_one();
    }

    int pop() {
        std::unique_lock<std::mutex> lock(mutex_);
        // CP.42: Always wait with a condition
        cv_.wait(lock, [this] { return !queue_.empty(); });
        const int value = queue_.front();
        queue_.pop();
        return value;
    }

private:
    std::mutex mutex_;             // CP.50: mutex with its data
    std::condition_variable cv_;
    std::queue<int> queue_;
};

Multiple Mutexes

// CP.21: std::scoped_lock for multiple mutexes (deadlock-free)
void transfer(Account& from, Account& to, double amount) {
    std::scoped_lock lock(from.mutex_, to.mutex_);
    from.balance_ -= amount;
    to.balance_ += amount;
}

Anti-Patterns

volatile for synchronization (CP.8 -- it's for hardware I/O only)
Detaching threads (CP.26 -- lifetime management becomes nearly impossible)
Unnamed lock guards: std::lock_guard<std::mutex>(m); destroys immediately (CP.44)
Holding locks while calling callbacks (CP.22 -- deadlock risk)
Lock-free programming without deep expertise (CP.100)

Templates & Generic Programming (T.*)

Key Rules

Rule	Summary
T.1	Use templates to raise the level of abstraction
T.2	Use templates to express algorithms for many argument types
T.10	Specify concepts for all template arguments
T.11	Use standard concepts whenever possible
T.13	Prefer shorthand notation for simple concepts
T.43	Prefer `using` over `typedef`
T.120	Use template metaprogramming only when you really need to
T.144	Don't specialize function templates (overload instead)

Concepts (C++20)

#include <concepts>

// T.10 + T.11: Constrain templates with standard concepts
template<std::integral T>
T gcd(T a, T b) {
    while (b != 0) {
        a = std::exchange(b, a % b);
    }
    return a;
}

// T.13: Shorthand concept syntax
void sort(std::ranges::random_access_range auto& range) {
    std::ranges::sort(range);
}

// Custom concept for domain-specific constraints
template<typename T>
concept Serializable = requires(const T& t) {
    { t.serialize() } -> std::convertible_to<std::string>;
};

template<Serializable T>
void save(const T& obj, const std::string& path);

Anti-Patterns

Unconstrained templates in visible namespaces (T.47)
Specializing function templates instead of overloading (T.144)
Template metaprogramming where constexpr suffices (T.120)
typedef instead of using (T.43)

Standard Library (SL.*)

Key Rules

Rule	Summary
SL.1	Use libraries wherever possible
SL.2	Prefer the standard library to other libraries
SL.con.1	Prefer `std::array` or `std::vector` over C arrays
SL.con.2	Prefer `std::vector` by default
SL.str.1	Use `std::string` to own character sequences
SL.str.2	Use `std::string_view` to refer to character sequences

// SL.con.1 + SL.con.2: Prefer vector/array over C arrays
const std::array<int, 4> fixed_data{1, 2, 3, 4};
std::vector<std::string> dynamic_data;

// SL.str.1 + SL.str.2: string owns, string_view observes
std::string build_greeting(std::string_view name) {
    return "Hello, " + std::string(name) + "!";
}

// SL.io.50: Use '\n' not endl
std::cout << "result: " << value << '\n';

Enumerations (Enum.*)

Key Rules

Rule	Summary
Enum.1	Prefer enumerations over macros
Enum.3	Prefer `enum class` over plain `enum`
Enum.5	Don't use ALL_CAPS for enumerators
Enum.6	Avoid unnamed enumerations

// Enum.3 + Enum.5: Scoped enum, no ALL_CAPS
enum class Color { red, green, blue };
enum class LogLevel { debug, info, warning, error };

// BAD: plain enum leaks names, ALL_CAPS clashes with macros
enum { RED, GREEN, BLUE };           // Enum.3 + Enum.5 + Enum.6 violation
#define MAX_SIZE 100                  // Enum.1 violation -- use constexpr

Source Files & Naming (SF., NL.)

Key Rules

Rule	Summary
SF.1	Use `.cpp` for code files and `.h` for interface files
SF.7	Don't write `using namespace` at global scope in a header
SF.8	Use `#include` guards for all `.h` files
SF.11	Header files should be self-contained
NL.5	Avoid encoding type information in names (no Hungarian notation)

Header Guard

// SF.8: Include guard (or #pragma once)
#ifndef PROJECT_MODULE_WIDGET_H
#define PROJECT_MODULE_WIDGET_H

// SF.11: Self-contained -- include everything this header needs
#include <string>
#include <vector>

namespace project::module {

class Widget {
public:
    explicit Widget(std::string name);
    const std::string& name() const;

private:
    std::string name_;
};

}  // namespace project::module

#endif  // PROJECT_MODULE_WIDGET_H

Naming Conventions

// NL.8 + NL.10: Consistent underscore_style
namespace my_project {

constexpr int max_buffer_size = 4096;  // NL.9: not ALL_CAPS (it's not a macro)

class tcp_connection {                 // underscore_style class
public:
    void send_message(std::string_view msg);
    bool is_connected() const;

private:
    std::string host_;                 // trailing underscore for members
    int port_;
};

}  // namespace my_project

Anti-Patterns

using namespace std; in a header at global scope (SF.7)
Headers that depend on inclusion order (SF.10, SF.11)
Hungarian notation like strName, iCount (NL.5)
ALL_CAPS for anything other than macros (NL.9)

Performance (Per.*)

Key Rules

Rule	Summary
Per.1	Don't optimize without reason
Per.2	Don't optimize prematurely
Per.6	Don't make claims about performance without measurements
Per.7	Design to enable optimization
Per.10	Rely on the static type system
Per.11	Move computation from run time to compile time
Per.19	Access memory predictably

Guidelines

// Per.11: Compile-time computation where possible
constexpr auto lookup_table = [] {
    std::array<int, 256> table{};
    for (int i = 0; i < 256; ++i) {
        table[i] = i * i;
    }
    return table;
}();

// Per.19: Prefer contiguous data for cache-friendliness
std::vector<Point> points;           // GOOD: contiguous
std::vector<std::unique_ptr<Point>> indirect_points; // BAD: pointer chasing

Anti-Patterns

Optimizing without profiling data (Per.1, Per.6)
Choosing "clever" low-level code over clear abstractions (Per.4, Per.5)
Ignoring data layout and cache behavior (Per.19)

Quick Reference Checklist

Before marking C++ work complete:

No raw new/delete -- use smart pointers or RAII (R.11)
Objects initialized at declaration (ES.20)
Variables are const/constexpr by default (Con.1, ES.25)
Member functions are const where possible (Con.2)
enum class instead of plain enum (Enum.3)
nullptr instead of 0/NULL (ES.47)
No narrowing conversions (ES.46)

Weekly Installs

506

Repository

affaan-m/everyt…ude-code

GitHub Stars

69.1K

First Seen

Feb 17, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

codex455

opencode447

gemini-cli434

github-copilot433

kimi-cli420

cursor419

React 组合模式指南：Vercel 组件架构最佳实践，提升代码可维护性

102,200 周安装

No C-style casts (ES.48)

Single-argument constructors are explicit (C.46)

Rule of Zero or Rule of Five applied (C.20, C.21)

Base class destructors are public virtual or protected non-virtual (C.35)

Templates are constrained with concepts (T.10)

No using namespace in headers at global scope (SF.7)

Headers have include guards and are self-contained (SF.8, SF.11)

Locks use RAII (scoped_lock/lock_guard) (CP.20)

Exceptions are custom types, thrown by value, caught by reference (E.14, E.15)

'\n' instead of std::endl (SL.io.50)

No magic numbers (ES.45)

现代C++编码标准指南：C++17/20/23核心准则与最佳实践

🇨🇳中文介绍

C++ 编码标准（C++ 核心准则）

使用时机

不适用时机

贯穿性原则

相关 Skills

哲学与接口（P., I.）

关键规则

推荐做法

不推荐做法

函数（F.*）

关键规则

参数传递

纯函数和 constexpr

反模式

类与类层次结构（C.*）

关键规则

零法则

五法则

类层次结构

反模式

资源管理（R.*）

关键规则

智能指针使用

RAII 模式

反模式

表达式与语句（ES.*）

关键规则

初始化

反模式

错误处理（E.*）

关键规则

异常层次结构

反模式

常量与不变性（Con.*）

所有规则

并发与并行（CP.*）

关键规则

安全加锁

多个互斥锁

反模式

模板与泛型编程（T.*）

关键规则

概念（C++20）

反模式

标准库（SL.*）

关键规则

枚举（Enum.*）

关键规则

源文件与命名（SF., NL.）

关键规则

头文件防护

命名约定

反模式

性能（Per.*）

关键规则

指导原则

反模式

快速参考检查清单

🇺🇸English

C++ Coding Standards (C++ Core Guidelines)

When to Use

When NOT to Use

Cross-Cutting Principles

Philosophy & Interfaces (P., I.)

Key Rules

DO

DON'T

Functions (F.*)

Key Rules

Parameter Passing

Pure Functions and constexpr

Anti-Patterns

Classes & Class Hierarchies (C.*)

Key Rules

Rule of Zero

Rule of Five

Class Hierarchy

Anti-Patterns