函数长度与文件长度是什么
长度是弱信号：超长往往意味着多重职责，但机械切割只会带来碎片函数。真正决定维护成本的是认知复杂度、嵌套深度与改动频率——一个 80 行平铺的配置构造，可能比 30 行四层缩进的算法好读得多。长度阈值的正确用法是触发阅读与讨论，而不是自动判罚。
基本信息
| 阈值示例 | 函数 >50 行、文件 >1000 行作为讨论触发点 |
|---|---|
| 伴随信号 | 认知复杂度、嵌套深度、被修改频率 |
| 动作 | 找到可命名的多职责再拆，而不是按行数切 |
| 统计口径 | 排除生成代码与测试数据，只看人工维护目录 |
拆前先回答
- 这个函数在做几件可以命名的事？
- 哪一段需要注释解释「做什么」，而不是「为什么」？
- 拆出的部分有独立测试价值吗？
- 被拆出的逻辑是否会被别处复用？
- 改动频率最高的部分能否单独隔离出来？
- 拆完以后调用链会不会长到需要跳三次以上？
拆前先自问与观察趋势
拆前先自问与观察趋势
□ 这个函数在做几件可命名的事？
□ 哪一段需要注释解释「做什么」？
□ 拆出的部分有独立测试价值吗？
# 趋势观察
- 新增长函数集中在哪个模块？回看分层设计是否缺失
- 长度榜单与变更频率榜单取交集，优先处理
- 生成代码、迁移脚本、测试数据文件排除在外长度信号解读
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 长函数 + 高频修改 | 职责混杂且持续演进 | 优先拆，收益最直接 |
| 长函数 + 几乎不改 | 一次性转换或初始化逻辑 | 观察，不急于动 |
| 文件长 + 多个主题 | 缺少模块划分 | 按变化原因拆包 |
| 大量短函数 + 深调用 | 过度分解 | 合并语义相近的小步骤 |
按行数自动判罚会诱导碎片化：把一个 60 行函数拆成六个 10 行函数，行数分布好看了，读者却要跳六次才能理解一条流程，理解成本反而上升。
统计时把生成代码、协议桩与测试数据排除在外，否则榜单会被无关内容挤满。文件长度更适合当作目录结构的提示：一个文件承载多个主题，通常说明模块划分需要重新审视。