谷歌工程师花10年推翻"短代码=好代码"：文件长度这指标，骗了整代程序员

200行是黄金标准？500行必须拆分？这些数字你大概听过。但谷歌软件工程师在维护大型系统十年后，发现整个行业对"文件太长"的理解，可能从一开始就跑偏了。

从" cluttered desk "到认知崩塌

作者最初的判断很直觉：长文件=乱，短文件=整洁。这种感受"几乎像物理直觉"——乱糟糟的桌子对比井井有条的桌子。但当他真正深入大型系统维护后，这套直觉失效了。

问题出在"太长"这个词本身。它不是一个描述，而是一个裁决。而裁决需要标准。文件对谁太长？太长而读不懂？太长而维护不了？剥掉"太长"的框架，真正的问题是：什么让代码难以理解和维护？

文件长度是一个症状，而非病因。

"短文件=好代码"怎么变成行业铁律

这个规范的起源其实很合理：在糟糕的代码库里，长度和混乱恰好同时出现。工程师们观察到相关性，于是把它从启发式经验提拔为绝对法则——却没人验证它在一般情况下是否成立。

实证研究给出了反直觉的结论。缺陷率研究显示曲线关系：极小的模块反而因接口表面过大而问题更多。认知负荷研究证实，将相关逻辑拆到过多小文件中，会真实增加理解成本。

换句话说，过度拆分和过度冗长一样有害。

为什么"长度完全无关"也是错的

另一个极端同样站不住脚。长度确实携带一个嘈杂但真实的信号：责任在累积。当文件膨胀，通常意味着它在做太多事。

但关键是区分信号和噪声。长度值得注意，应该作为提问的提示，而非答案本身。看到800行文件，第一反应不该是"必须拆"，而是"这些东西真的属于一起吗？"

该在一起的就要在一起；行数只是这个结果，不是目标。

cohesion 才是唯一标准

代码质量的真正准则是 cohesion（内聚性）——文件里的内容是否属于彼此。长度只是这个判断的副产品。

一个300行的文件，如果所有逻辑紧密相关，可能比三个100行但频繁互相调用的文件更易维护。反之，一个150行的文件如果混杂了不相关的责任，拆分反而是正确的。

作者没有给出具体行数建议。他的立场是诚实的：没有普适数字。行业需要放弃对度量的迷信，回到更困难但更重要的问题——这段代码在做什么，为什么这些部分需要共处一室？

当你下次看到"文件过长"的警告，或者准备按行数阈值强制拆分时，不妨先问：我是在解决 cohesion 问题，还是在用行数逃避思考？