嵌套深度是什么
控制流嵌套层数直接影响可读性与出错率：读代码的人需要在脑中同时维持多个条件。经验上超过三到四层就该触发重构讨论。它比函数长度更贴近认知负担——同样 40 行的两个函数，一个平铺直叙、一个四层缩进，维护成本完全不同。
基本信息
| 度量 | if、for、while、try 的嵌套层级 |
|---|---|
| 手段 | 卫语句提前返回、提取函数、查表替代分支 |
| 经验阈值 | 超过 3-4 层触发重构讨论 |
| 统计口径 | 排除生成代码与数据文件，只统计人工维护目录 |
降低嵌套的常用手段
- 卫语句：把异常与边界情况提前返回，主线逻辑回到最外层
- 提取函数：每一层循环或判断体命名成一个函数，层次即刻扁平
- 查表：把多分支判断换成映射表加一次查找
- try 块缩小：只包住真正可能抛错的语句，避免把后续逻辑卷进缩进
- 布尔表达式的德摩根变换：合并前置条件，减少一次嵌套
- 用集合操作替代嵌套循环：过滤与映射交给语言自带的管道
深层嵌套改造
深层嵌套改造
// 之前：四层缩进，读者要同时记住 a、b、c、d
if (a) {
if (b) {
if (c) {
if (d) { work(); }
}
}
}
// 之后：卫语句承担边界判断，主线保持平铺
if (!a || !b) return;
if (!c || !d) return;
work();
// 分支很多时改用查表
Map<Type, Handler> table = Map.of(A, this::handleA, B, this::handleB);
table.getOrDefault(type, this::handleDefault).run();手段对照
| 手段 | 适用 | 代价 |
|---|---|---|
| 卫语句 | 前置校验、边界条件 | 函数出现多个返回点 |
| 提取函数 | 单层逻辑较长或有命名价值 | 调用层次增多 |
| 查表 | 分支多且互斥 | 需要维护表结构 |
| 多态替换条件 | 分支与类型一一对应 | 类型数量上升 |
| 集合管道 | 嵌套循环做过滤与转换 | 调试断点不便 |
为降低层数把条件塞进一个巨大的布尔表达式，只是把缩进换成了括号：读起来更难的表达式并不比多层嵌套好。目标是让每个判断有名字、能被单独讨论。
不是所有深层嵌套都该改：解析器、递归算法、状态机这类逻辑天然带层级。判断依据是「这一层是否对应一个可命名的概念」，能命名就该提炼。