什么时候函数太长？我认为是这个问题的一个子集。
确定类太长的几个好的指标是什么？
我正在为一个与外部承包商的项目重新修订一组代码验收指南，并意识到我过去没有涵盖这一点，但将来应该涵盖这一点。
问问题
17643 次
6 回答
63
When it has more than one responsibility.
Let me quote Robert C. Martin's Clean Code here:
The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that. ... With functions we measured size by counting physical lines. With classes we use a different measure. We count responsibilities. [Chapter 10, page 136]
于 2010-02-08T16:00:20.060 回答
19
类扇出复杂度：给定类所依赖的其他类的数量。此外，它的平方已显示至少表示功能程序（基于文件）所需的维护量。
圈复杂度：根据指定限制检查圈复杂度。复杂性通过 if、while、do、for、?:、catch、switch、case 语句以及运算符 && 和 || 的数量来衡量。（加一）在构造函数、方法、静态初始化程序或实例初始化程序的主体中。它是通过源的最小可能路径数量的度量，因此是所需测试的数量。一般 1-4 认为好，5-7 ok，8-10 考虑重构，11+ 现在重构！
于 2010-02-09T08:54:34.143 回答
9
不超过 17 行。不多也不少。因此，如果在 17 行以下，回车就可以解决问题。如果超过 17，您将需要从函数中开始调用其他函数。
例如：
public function myFunction() {
...
line 17: myFunctionPart2();
}
public function myFunctionPart2() {
...
line 17: myFunctionPart3();
}
等等。
它非常标准的编程实践。
于 2010-02-08T16:28:49.793 回答
4
一个班级应该只有一个职责。这比它的长度更好。因此，在设计代码时，设计的每个单元（类型或类）应该只负责一件事（无论您的情况是什么“一件事”）。如果你让它尽可能简单，你就不会陷入混乱。
于 2010-02-08T16:00:47.307 回答
2
当您认为现在管理它变得更加困难并让您陷入困境时。
于 2010-02-08T16:01:57.047 回答
2
忽略使用中的设计模式，我会考虑类履行的责任范围。如果范围太大，则应将其分解为具体的职责、抽象出来或变得更通用。
我实际上不会将行数作为有意义的指标。
于 2010-02-08T16:03:47.630 回答