软件质量，不但依赖于架构及项目管理，更与代码质量紧密相关。简洁高效的代码不但易于阅读，更能避免潜在 Bug 与风险，提高代码质量。这是显而易见的道理，但是要做到这个标准可不容易。想想看，据说 Oracle 12.2，有近 2500 万行代码，是不是很恐怖？你能做到在不破坏成千上万个现有测试的情况下更改这样产品中的单单一行代码吗？很难，对吧？要想避免这样的情况，就要从源头做起。“30”规则就是一个很好的办法，让我们看看 Riccardo Giorato 是怎么说的？

正文：

如果你在编程中，不考虑代码长度的话，那么可维护性、未来更新或对代码库的更改，都将会变得异常困难。

方法或函数的大小应该多大呢？

我们都遇到过这样的问题，当一个函数太长的时候。

或者类，或者包，或者任何其他代码块。在某些情况下，任何一段代码都有可能会变得过于庞大，以至于他人无法正确理解。但是，多大才算大呢？

在 Code Complete （《代码大全》，金戈等人译，电子工业出版社）， Steve McConnell 指出，理论上，一个方法或函数的最佳最大限制是在一个屏幕上可以容纳的行数。

这种“适合屏幕”的尺寸相当于 65~200 行之间的函数的最佳点。这种大小的例程开发成本更低，每行代码的错误也更少，而且它们的可维护性也很高。

如果你写的代码超过了 200 行，那么，你就会进入了“危险区”：代码的可读性和正确性即将开始崩溃。

30 行代码规则

找寻找更严格的指导原则时，你可以在 Stephen Roock 和 Martin Lippert 合著的 Refactoring in Large Software Projects （《大型软件项目的重构》，暂无中文版）一书中找到“30”规则：

如果一个元素包含超过 30 个子元素，那么极有可能会存在严重的问题：

a) 方法的平均代码行数不应超过 30 行（不含行空和注释）；

b) 一个类应该包含平均少于 30 个方法，最多可以包含 900 行代码；

c) 一个包包含的类不应超过 30 个，因此最多可包含 27000 行代码；

d) 应当避免使用超过 30 个包的子系统。这样一个子系统最多包含 900 个类，810000 行代码；

e) 因此，一个有 30 个子系统的系统，将拥有 27000 个类，2430 万行代码。

你应该遵循这些规则吗？如何做？

使用代码大小作为编码规则还是非常友好的；对于每个开发人员来说，无论年轻还是碾场，都很容易看到、理解。其他度量，如用于度量代码质量的循环复杂度（cyclomatic complexity），通常更难掌握，并且需要外部工具进行检查。

将类或函数长度限制在这些值范围内将是一个更好的起点，而不是对你的团队或开发人员没有真正的参考。你还会发现，当你审查或更新代码时，这“30”规则的真正价值是显而易见的。

试图将这些规则作为法律或强制性规则来执行，反而会让你置于危险之中——这并不是他们的目标。当你在编写方法中写到第 31 行时，你不会希望停下写代码，对吧？

此举将会降低工作速度，并迫使每个人都将代码分解以适应任意的大小限制，这将使他们的代码风格变得更糟，而不是更好。

正如 Jeff Langer 在讨论 Ken Beck 在 Clean Code （《代码整洁之道》，韩磊译，人民邮电出版社）一书中提到的简单设计的四条规则那样：

我们的目标是保持函数和类短小的同时，保持整个系统短小精悍。不过要记住，这在关于简单设计的四条规则里面是有限相机最低的一条。所以，尽管使类和函数的数量尽量少是很重要的，但更重要的确实测试、消除重复和表达力。

有时候，要完成一份连贯的工作需要 30 行或多或少的的代码。

更重要的是，在编写类时要小心，要考虑自己在这里添加了多少东西，其他人会理解这些结构和函数的分组吗？我应该分割这个文件呢，还是讲这个类与另一个类合并呢？

“30”规则将会给你带来帮助，但你必须不能让它支配你！