发帖
雷达卡
（二）命名规范就像给孩子起名字一样讲究
变量命名绝不能图省事，杜绝使用 a、b、c 这类毫无意义的符号。我们团队严格执行以下命名规则：类名采用大驼峰格式（如 DataManager），函数名使用小驼峰格式（如 parseConfigFile），宏定义则必须全大写并用下划线分隔（如 MAX_BUFFER_SIZE）。
成员变量统一以 m_ 开头（如 m_isValid），静态变量加 s_ 前缀（如 s_instance）。至于全局变量，尽量避免使用；若确实需要，务必加上 g_ 前缀（如 g_logLevel）以示区分。
布尔类型的变量命名必须体现其语义，应以 is、has 或 can 开头，例如 isReady、hasPermission。禁止使用 flag1、flag2 这种让人摸不着头脑的名称。
（三）缩进与空格的规范细节
项目组已统一采用 4 个空格进行缩进，严禁使用 Tab 字符。在 Visual Studio 中可通过【工具→选项→文本编辑器→C++→制表符】设置为“插入空格”来实现。
运算符前后必须保留空格，例如：int sum = a + b;，但指针声明时星号紧邻类型，如 char* buffer。
函数参数列表中，逗号后需添加一个空格，如 connect(string ip, int port)。
条件或循环语句中的关键字 if、for 后面必须跟一个空格，正确写法为：for (int i = 0; i < count; ++i)。
（四）头文件保护机制不可忽略
每个头文件都必须包含防护措施，推荐使用 #pragma once，相比传统的 #ifndef/#define/#endif 更简洁且不易出错。
（五）函数设计的基本原则
单个函数的代码行数不得超过 50 行，超过 30 行就应考虑是否需要拆分为多个小函数。函数参数数量建议控制在 5 个以内，若过多则应封装成结构体传递。
参数排列顺序遵循输入在前、输出在后的原则。输入参数尽可能使用 const 引用方式传递，例如：void updateUser(const UserInfo& user)。
返回值优先使用智能指针而非原始指针，并对可修饰为 const 的内容明确标注，提升安全性和可读性。
（六）专业级注释的书写方式
头文件中的注释推荐采用三线格式，清晰标明功能、作者和日期等信息。
函数注释必须详细说明各个参数的意义及返回值含义，示例如下：
/**
* 解析配置文件
* @param filename 配置文件路径（输入）
* @return 成功返回 true，失败返回 false
*/
bool parseConfigFile(const string& filename);
行内注释统一使用 // 形式，禁止嵌套使用 /* */ 注释块。关键逻辑流程必须配有注释，但像 int i = 0; 这类显而易见的操作无需额外解释。
（七）内存管理的硬性要求
禁止直接调用 new 和 delete，所有动态内存管理必须通过智能指针完成。对象创建优先使用 make_shared 或 make_unique 辅助函数。
当容器存储的是对象指针时，应使用嵌套的 shared_ptr 结构，例如：shared_ptr<vector<shared_ptr<Student>>>。
循环体内不得频繁申请大块内存，任何超过 1KB 的缓冲区应在循环外部预先分配。
涉及文件操作或网络连接的资源，必须通过 RAII 机制进行封装，确保即使发生异常也能正确释放资源。
（八）异常处理的标准做法
构造函数若初始化失败，必须抛出异常，不允许依赖后续的 Init() 方法进行二次初始化。
捕获异常时要按具体到抽象的顺序处理，先 catch 派生类异常，再 catch 基类异常，防止异常被错误地屏蔽。
（九）紧跟现代 C++ 发展步伐
在类型明显可推导的情况下，优先使用 auto 简化声明，但容器迭代器等关键位置仍建议显式写出类型以增强可读性。
遍历容器时首选范围 for 循环，例如：for (const auto& item : itemList)。
返回局部对象时可放心依赖移动语义，现代编译器会自动优化返回过程。
Lambda 表达式的使用要适度，避免过度嵌套导致代码难以维护。
（十）最后的一些提醒
编码规范的目的不是限制个人发挥，而是为了提高团队协作效率和代码一致性。建议在持续集成（CI）流程中集成 clang-tidy 工具进行静态检查，并在每次提交前运行 cppcheck 扫描潜在问题。
请始终记住：优秀的代码首先是写给人看的，其次才是让机器执行。下个月我们将组织一次全员代码评审活动，届时未遵守规范的同学将请全组喝奶茶！
[此处为图片1]
京公网安备 11010802022788号
