每个包有多少班？每班的方法？每种方法的线？

我必须对一些巨大的Java项目给出一般性的说明,但我很少见,我想知道是否有任何指导方针来确定:

每个包的类数可以被认为是正确的,低的还是高的(这个项目每个包有3.89个类,这对我来说似乎有点小),

每班的方法数量？(这个项目每班有6.54个方法......

每种方法的行数？(这个项目每个方法大约有7行(对我来说似乎很好,可能有点低))

我应该注意到这个问题只涉及体积测量.我从质量工具(checkstyle,jdepend,cpd,pmd,ncss)获得了大量报告,这些报告让我对代码冗余,类使用,错误等有了更多的了解.

1> Yona..：

---

史蒂夫麦康奈尔在他的书"代码完成"中推荐每个类约7种方法,然后在一个方法中不再有行可以在不滚动的情况下在单个屏幕中查看.

我不确定每个包的类.

我强烈建议您阅读Code Complete以获取有关此类主题的更多信息.

---

我认为这个建议过于简单化了.我们不会将一个类分成两个,因为它们有七个以上的方法.我们需要主要考虑凝聚力.

---

您不进行拆分只是因为有七种以上的方法 - 但是这个指标会将您的注意力引导到(可能)需要重构的类.

---

这些不切实际的限制的问题是,最终你知道你不会跟随它们,就好像它们不在这里一样(每个方法可以达到双线？在MVC控制器中可以达到三倍？方法太小了,你允许双倍？).我说我们需要一个实用的代码实践,它实际上提供了很好的例子和现实的期望.

2> Mauro..：

---

我认为像这样的统计数据是非常无用的,知道每个方法的行数如何显示它对项目是否有用; 我认为你应该更多地看待:

你的包裹是否包含类似的课程？

您的课程是否自己作为一个实体工作？

类中的方法是否正确有效地运行？

当然,除了内存使用之外,方法是否很大并不重要？在非常长时间的方法中寻找的另一件事是堆栈跟踪是否比将该功能添加到父方法更大.我会谨慎地根据代码行测量项目的成功.

---

绝对是一个方法有多大,因为a)方法的读取次数比写入方式多,b)小方法更容易理解.

3> Peter Evjan..：

---

最近发布"清洁代码"一书的罗伯特·C·马丁表示,每种方法的线数应尽可能绝对最小.在1-7行之间是一个很好的经验法则.

在杰夫·贝(Jeff Bay)的文章"对象健美操"(Object Calisthenics)中,"思想工具集"(ThoughtWorks Anthology)一书中也有一个很好的观点.他建议9个非常严格的约束条件,从长远来看,这将使你成为一个更好的OO开发者.在这里阅读更多相关信息.

要回答您的具体问题,这些是您特别要求的限制: - 每个包不超过10个类 - 每个类最多50行

这些约束对于你所有的真实项目可能并不理想,但在一个小的(业余爱好？)项目中使用它们会迫使你进入更好的实践.

---

每个类50行似乎对我来说很小,你算整个文件还是只计算语句？因为如果它是整个文件,则50行非常小或不包含注释.

4> Itay Maman..：

---

不幸的是,软件中没有绝对的(客观的)质量概念.因此,这些没有"正确"的价值.但是,这里有两个(个人)的观点:

3.89班/包非常低.这意味着你将在一个复杂的包树丛中战斗.

每种方法7行:确实听起来不错.但是,如果这些数字是由于有意减少方法的行数而得出的,那么您可能最终会将一个逻辑任务分散到几个私有方法中,这将使得理解该类更加困难(在某些情况下).实际上,在CodeComplete-2中,作者引用了一项研究,该研究发现方法长度远不如其圈复杂度及其嵌套水平重要.

5> Brian Rasmus..：

---

一个有用的设计指南说每个班级应该只做一件事并且做得好.这不会为每个类提供固定数量的方法,但它会限制数量并使类更易于理解和维护.

对于方法,您可以采用类似的视图,并针对尽可能小但不小的方法.可以这样想:如果你可以将方法分成两个或多个不同的部分,那么它显然不会像它那样小.小方法很容易理解,通过拆分这样的代码,您可以在高级方法中获得更好的概述,并将细节推送到低级方法.