应将长条件表达式拆为带明确语义的布尔变量，如is_authenticated、is_admin_role等，紧邻if声明，避免短路求值丢失、命名歧义和过度原子化。
直接拆成带明确语义的布尔变量最安全，但必须避开短路求值丢失、命名歧义、过度原子化这三类坑。
用局部bool变量替代长条件表达式
把一整行 if (user.is_authenticated() && user.role != "guest" && !config.disable_api && request.timestamp > last_rate_limit) 拆开，不是为了“看起来整洁”，而是让每个子条件可单独测试、可复用、可加断点调试。
- 每个变量只封装一个有业务含义的状态，比如
is_authenticated、is_admin_role、api_enabled、is_rate_limited - 定义位置紧挨着
if，不提前提到函数开头——避免别人误以为它是贯穿整个函数的“状态缓存” - 别写
bool flag1 = ...; bool flag2 = ...;，这种命名等于没拆；也别把x > 0 && x 拆成 <code>is_positive和is_under_hundred，它本就是一个原子范围判断
警惕短路求值消失带来的逻辑变化
原始表达式 a && b() 中，若 a 为 false，b() 根本不会执行。但一旦写成 bool a_ok = a; bool b_ok = b(); if (a_ok && b_ok)，b() 就必然被执行——可能触发副作用（如日志、IO、状态变更）或性能问题。
- 如果子表达式含函数调用且有副作用，优先封装为内联函数，比如
bool can_access_resource()，而不是存结果到变量 - 若必须用变量缓存，得确认该调用是幂等的、无副作用的，且结果在当前作用域内不会过期
- 嵌入式场景尤其要注意：某些硬件寄存器读取会触发状态翻转，重复读就错
正向命名 + 显式否定，别用双重否定词
写 if (!is_disabled && !is_expired && is_ready)，三秒内没人能理清真实进入条件。更糟的是和别人代码混用时，is_not_ready 和 !is_ready 同时出现，真假关系瞬间混乱。
- 只用肯定式命名：
is_valid、has_permission、should_retry - 否定逻辑一律用
!运算符表达，不塞进变量名里 - 组合时直接写
if (!is_valid || !has_permission)，视觉上清晰，编译器优化也不受影响
什么情况不该拆？直接上函数或 constexpr
拆不是万能解药。有些判断天生就不适合用普通变量存一次结果。
- 涉及 IO、系统调用、时间敏感状态（如
is_network_up()），必须用函数——否则第一次判断后网络断了，变量还一直为 true - 编译期就能确定的开关，比如
constexpr bool enable_debug_log = true;，用constexpr而非运行时bool，零开销且语义更准 - 跨作用域复用的复杂判断，别在每个
if前重复定义变量，直接抽成inline函数，既安全又避免复制粘贴错误
真正难的不是“怎么拆”，而是判断某个子表达式到底属于静态配置、瞬态状态，还是带副作用的动作——这个分界线划错了，后面所有命名、缓存、复用都会跟着错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
