变量命名核心原则是用最短无歧义的词准确表达其在当前上下文中的业务含义，避免缩写、类型冗余和模糊名称，布尔变量须以is_/has_/can_开头，作用域越大名字越需自解释。
变量名要能一眼看出用途，不是为了编译器，是为了三个月后的你自己
编译器不在乎你叫 tmp 还是 user_login_timestamp_ms，但你在凌晨两点调试一个内存越界时，看到 x 和 val 会想砸键盘。起名的核心原则只有一条：**用最短的、无歧义的词，准确表达这个变量「在当前上下文中到底存什么」**。
别用缩写，除非是全行业公认的
缩写省不了多少键入时间，却大幅增加理解成本。比如 usr 不如 user，cnt 不如 count，sz 在不同项目里可能指 size、socket_zombie 甚至 screen_zoom —— 它根本不是缩写，是谜语。
公认的例外极少：id（identifier）、rgb、http、xml、std::string 里的 str（仅限极短作用域，如循环内 for (const auto& str : vec)）。
-
i、j只允许在简单 for 循环里作索引，且必须是紧邻的、无嵌套的场景；嵌套循环或带条件跳转时，立刻换成row_idx、col_idx -
ptr后缀（如buffer_ptr）没必要 —— 类型系统已经告诉你它是指针，加后缀反而干扰阅读 -
m_前缀（成员变量）和s_（静态变量）在现代 C++ 里越来越不被推荐；用作用域和 const 正确性比靠命名约定更可靠
类型信息尽量交给编译器，别塞进名字里
写 user_name_str 是在重复声明类型，而 std::string user_name 已经足够清晰。C++ 的强类型不是摆设，滥用匈牙利命名法（pszName）只会让名字又长又难读，还容易过时 —— 比如你把 user_name_str 改成 std::string_view，名字就立刻失效了。
真正该放进名字的是「业务含义」：
- 用
user_id而不是id（避免和group_id、session_id混淆） - 用
max_retries而不是retry_count（前者强调约束，后者易误解为当前值） - 用
is_authenticated而不是auth_flag（布尔变量必须以is_、has_、can_开头，这是读代码时的语法锚点）
作用域越小，名字可以越短；作用域越大，名字必须越精确
函数内部临时变量 i、it、tmp 没问题；但跨多个函数、作为类成员、或出现在头文件里被外部包含的变量，名字必须自解释。
一个典型反例：data —— 它可能是原始字节、序列化 JSON、数据库查询结果、还是用户输入缓存？没有上下文根本无法判断。换成 raw_http_response_body 或 cached_user_profile_json，调用方一眼就知道能不能直接用、要不要深拷贝、是否线程安全。
容易被忽略的一点：**模板参数名也得认真起**。别写 template<typename t></typename> 就完事。如果是容器元素类型，用 ElementType；如果是可调用对象，用 Callable；如果代表某种策略，用 Policy —— 这些名字会在 IDE 提示、错误信息（比如 static_assert 失败时）里直接出现，含糊其辞只会拖慢排查速度。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
