成员变量统一加后缀_是主流做法,如name_、value_,可避免参数名冲突、初始化列表歧义及未定义行为,google/llvm等项目均采用;参数应体现意图,如new_age、target_time,禁用同词回环和单下划线开头命名。

成员函数参数名不能和成员变量同名,否则会遮蔽
直接写 void setName(std::string name) { name = name; } 是错的——右边的 name 会被解释为参数,赋值没效果。编译器不会报错,但逻辑失效,这是最隐蔽的 bug 来源之一。
- 用前缀或后缀区分:比如成员变量叫
name_,参数就叫name;或者成员变量叫m_name,参数也叫name - 避免用
_name(单下划线开头):C++ 标准保留所有双下划线或以下划线+大写字母开头的标识符,_name属于未定义行为风险区 - 不推荐靠
this->补救:虽然this->name = name;能工作,但它把命名责任推给调用方,增加阅读负担,且无法防止漏写this->
类成员变量统一加后缀 _ 是当前主流选择
Google C++ Style、LLVM、Chromium 等大型项目都用 value_、buffer_size_ 这种风格。它比 m_value 更轻量,比无标记更安全,也比 this-> 显式写法更简洁。
组合式C++代码评审方案,融合静态分析、AI推理、多轮迭代评审和C++专项检查,适用于PR审查、增量代码审查、全项目评审和代码质量评分,触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 后缀
_不影响 ADL(参数依赖查找),也不干扰模板推导 - IDE 和静态分析工具(如 clang-tidy)对
_后缀有良好支持,能自动高亮、补全、检查未初始化 - 注意:不要在局部变量或函数参数上滥用
_,只留给成员变量——否则会削弱它的语义提示作用
参数命名要体现意图,而不是类型
别写 void setAge(int age) 这种“同词回环”。如果参数用途明确,优先用更具体的动词或上下文限定词:
-
void setAge(int new_age)—— 清晰表达“这是要设的新值” -
void setDeadline(std::chrono::time_point deadline)→ 改成setDeadline(std::chrono::time_point target_time),避免和类型名重复 - 布尔参数尤其敏感:
enable_logging比logging好,is_async比async更不易误读 - 如果参数是回调或策略对象,用
on_complete、comparator这类能反映角色的名称,而不是cb或func
构造函数初始化列表里,参数和成员变量命名冲突最常见
初始化列表没有作用域嵌套,MyClass(int value) : value(value) {} 看似合理,实则危险——有些编译器允许,但语义模糊,Clang 会警告 -Wshadow-field。
- 初始化列表中必须确保左侧是成员变量名,右侧是参数名,所以成员变量带
_就天然规避这个问题:MyClass(int value) : value_(value) {} - 如果团队坚持不用后缀,那就强制参数加前缀,比如
arg_value或in_value,并在代码规范里明确定义 - 切忌在初始化列表里写
this->value = value:这不是初始化,是赋值,可能绕过 move 构造或引发未定义行为
id_ 写成 id,就可能在某个 if (id == 0) 里悄悄读到未初始化的栈垃圾。C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!










