c++编码规范

关于我的 C++ 编码规范：让代码清晰、可靠、易维护
刚开始写 C++ 时，我最关心的是程序能不能编译、结果对不对。随着代码变多，我逐渐发现，能运行只是起点：如果变量名含糊、逻辑挤在一起、资源管理不清楚，代码即使暂时正确，也会给之后的修改和协作带来麻烦。
因此，我希望建立一套适合自己的编码习惯。它不是一份必须照搬的规则清单，而是帮助我写出更清楚、更可靠代码的约定。若项目或团队已有统一规范，我会优先遵循项目要求。
统一格式，让结构更容易看懂
我习惯使用四个空格缩进，不混用 Tab。条件判断、循环和函数体都使用大括号，即使内部只有一条语句，也不省略。这样代码层级更清楚，日后增加逻辑时也不容易意外改变控制范围。
cpp
if (account.is_active()) {
account.refresh();
} else {
log_inactive_account(account.id());
}
运算符两侧、逗号后保留空格，不同功能的代码块之间适当留空行。遇到较长的表达式，我会按照逻辑拆行或提取变量，而不是把整段代码塞进一行。排版的目标是减少阅读负担，而不是单纯追求某种形式。
命名清晰，表达代码意图
变量、函数和类型的名称应尽可能说明用途。比如 retry_count 比 n 更容易理解，calculate_discounted_price 也比 do_work 更能说明函数职责。
我会在同一项目中保持命名风格一致。常量可依照项目约定命名；宏通常使用全大写和下划线，但在现代 C++ 中，能用 constexpr、const 或模板表达时，我会优先考虑这些语言特性。全局可变变量则尽量少用，避免数据从哪里被修改变得难以追踪。
及时初始化，控制变量作用范围
变量应尽量在定义时初始化。这样可以避免意外使用未确定的值，也让初始状态一目了然。变量最好在真正需要的地方声明，并尽可能缩小作用范围；如果对象不需要修改，就用 const 表达这一点。
cpp
int retry_count = 0;const bool is_valid = true;
复杂条件可以通过括号、拆分步骤或提取有意义的变量来表达，避免读者必须依赖对运算符优先级的记忆。清楚的表达通常比压缩代码更重要。
函数尽量专注，接口尽量明确
一个函数尽量只负责一件清楚的事。如果一个函数同时解析输入、访问文件、更新状态并打印结果，理解、测试和修改都会变得困难。适当拆分职责后，函数更容易复用，也更容易定位问题。
函数名应表达行为，参数和返回值应具有明确含义。可能失败的操作不能悄悄忽略错误，应按照项目约定，通过返回状态、错误信息或适当的错误类型，让调用者知道发生了什么。函数注释则应补充调用者需要了解的信息，而不是逐行复述实现。
使用合适的类型，谨慎处理边界
类型选择会影响代码的安全性和可读性。我会避免无意的隐式转换，并留意整数溢出、数组或容器下标越界、空指针等边界问题。譬如对于涉及金额的计算时，不应简单地把 double 当作精确货币类型；可以根据业务需求使用最小货币单位的整数，或专门的货币类型。
下面以折扣计算为例，展示清晰命名、初始化、常量和边界判断：
cpp

include #include

constexpr double kDiscountRate = 0.9;
// 计算折扣后的价格。负数价格按无效输入处理。double calculate_discounted_price(double price){
if (price < 0.0) {
return 0.0;
}

return price * kDiscountRate;
}
int main(){
const std::vector prices = {100.0, 50.0, 0.0};

for (const double price : prices) {
const double discounted_price =
calculate_discounted_price(price);

std::cout << "Discounted price: "
<< discounted_price << '\n';
}

return 0;
}
在真实的金额处理程序中，我会进一步采用适合业务的精确表示方式，并明确无效输入的处理规则。
让资源管理有明确归属
C++ 中的内存、文件、锁等资源都需要妥善管理。我会优先使用标准库容器和智能指针，减少手动申请与释放带来的遗漏。只有一个明确所有者时，通常优先使用值语义或 std::unique_ptr；确实需要共享所有权时，再考虑 std::shared_ptr。原始指针和引用可以用于表示借用关系，但应让资源归属保持清楚。
注释解释“为什么”，而不是“做了什么”
代码本身已经表达的内容，通常不需要再写一遍注释。注释更适合说明设计原因、业务规则、特殊边界或不直观的限制。函数上方的说明应简洁、准确，并在代码修改后及时更新。
过时的注释可能比没有注释更容易误导人。临时调试代码、不再使用的实现和无效注释也应及时清理；代码历史可以交给版本管理保存。
数据结构先讲清语义，再考虑优化
结构体成员的顺序首先应让人容易理解。单纯为了减少内存而按类型大小排序，不一定值得；实际布局还会受到编译器和对齐规则影响。只有当内存占用确实重要时，我才会结合需求和测量结果考虑布局优化，并确保代码仍然易读。
规范之外，还要测试和检查
代码格式统一不能保证程序正确。完成修改后，我会检查边界条件、失败路径和异常输入，并运行相关测试。团队也可以使用自动格式化、静态检查和代码审查，减少重复的人工检查，把更多精力留给设计和逻辑问题。
对我来说，好的 C++ 代码不只是“现在能够运行”，还应该让别人看得懂它的意图，知道错误该从哪里查，也能在未来安全地修改。编码规范的价值不在于条目有多少，而在于它们能否被持续使用，并真正降低理解、协作和维护的成本。