【发布时间】：2008-10-09 20:27:32
【问题描述】：
我想知道是否有人经常使用指标来验证其代码/设计。 例如，我想我会使用：
- 每个方法的行数 (
- 每个方法的变量数 (
- 每个方法的参数数量 (
- 每个类的方法数 (
- 每类的字段数 (
- 继承树深度 (
- 方法缺乏凝聚力
这些指标中的大多数都非常简单。
您对这种措施有什么政策？您是否使用工具来检查它们（例如 NDepend）？
【问题讨论】：
【发布时间】：2008-10-09 20:27:32
【问题描述】：
在我看来，对这些值施加数字限制（正如您似乎暗示的那样）不是一个好主意。如果有重要的 switch 语句，方法中的行数可能非常多，但方法仍然简单正确。如果字段很简单，则类中的字段数可以适当地非常大。有时，五级继承可能太多了。
我认为最好分析类内聚（越多越好）和耦合（越少越好），但即便如此我还是怀疑这些指标的实用性。经验通常是更好的指南（尽管无可否认，这很昂贵）。
【讨论】：
我在您的列表中没有看到的一个指标是 McCabe 的圈复杂度。它衡量给定功能的复杂性，并与错误相关。例如。函数的高复杂度分数表明：1) 可能是一个有问题的函数，2) 可能很难正确修复（例如修复将引入它们的自己的错误）。
归根结底，指标最好在总体水平上使用，例如控制图。您寻找高于和低于控制限的点以识别可能的特殊情况，然后查看详细信息。例如，具有高圈复杂度的函数可能会导致您查看它，却发现它是合适的，因为它是具有多种情况的调度程序方法。
【讨论】：
指标管理不适用于人员或代码；没有任何指标或绝对值总是有效的。请不要让对指标的迷恋分散了真正评估代码质量的注意力。指标似乎可以告诉您有关代码的重要信息，但它们能做的最好的事情就是提示要调查的领域。
这并不是说指标没有用。指标在变化时是最有用的，用于寻找可能以意想不到的方式变化的区域。例如，如果您突然从 3 级继承变为 15，或者每个方法的 4 个参数变为 12，请深入挖掘并找出原因。
示例：更新数据库表的存储过程可能具有与表的列数一样多的参数；此过程的对象接口可能具有相同的接口，或者如果存在表示数据实体的对象，则它可能具有相同的接口。但是数据实体的构造函数可能具有所有这些参数。那么这方面的指标会告诉你什么？不多！而且，如果您在代码库中有足够多的此类情况，那么目标平均值将被吹出水面。
因此，不要将指标作为任何事物的绝对指标；阅读/审查代码是无可替代的。
【讨论】：
我个人认为很难遵守这些类型的要求（即，有时您确实需要一个超过 20 行的方法），但本着您的问题的精神，我会提到一些在名为Object Calisthenics的文章（如果您有兴趣，请加入Thoughtworks Anthology）。
- 每个方法的缩进级别 (
- 每行的“点”数 (
- 每类的行数 (
- 每个包的类数 (
- 每个类的实例差异数 (
他还主张不要使用“else”关键字，也不要使用任何 getter 或 setter，但我认为这有点过火了。
【讨论】：
硬数字并不适用于所有解决方案。有些解决方案比其他解决方案更复杂。我会从这些作为你的指导方针开始，看看你的项目最终会在哪里结束。
但是，就这些数字而言，这些数字似乎相当高。我通常会发现我通常拥有的特定编码风格：
- 每个方法的参数不超过 3 个
- 每个方法签名大约 5-10 行
- 不超过 3 级继承
这并不是说我从不复习这些概括性，但我通常会在做的时候更多地考虑代码，因为大多数时候我可以将事情分解。
【讨论】：
正如其他人所说，保持严格的标准会很困难。我认为这些指标最有价值的用途之一是观察它们如何随着应用程序的发展而变化。这有助于让您了解在添加功能时完成必要的重构方面做得有多好，并有助于防止造成大混乱:)
【讨论】：
OO Metrics 对我来说有点像一个宠物项目（这是我硕士论文的主题）。所以是的，我正在使用这些并且我使用自己的工具。
多年来，Mark Lorenz 所著的“面向对象的软件度量”一书是 OO 度量的最佳资源。但是最近我看到了更多的资源。
很遗憾，我还有其他截止日期，所以没有时间使用该工具。但最终我会添加新的指标（和新的语言结构）。
更新 我们现在正在使用该工具来检测源中可能存在的问题。我们添加的几个指标（并非都是纯 OO）：
- 断言的使用
- 魔术常量的使用
- cmets 的使用与方法的复杂性有关
- 语句嵌套级别
- 类依赖
- 一个类中的公共字段数
- 被覆盖方法的相对数量
- goto 语句的使用
还有更多。我们保留那些能够很好地反映代码中的痛点的那些。因此，如果这些问题得到纠正，我们会提供直接反馈。
【讨论】：