不良气味审查代码影响方法？

Question

G'day，

我在考虑关于我对question关于软件开发质量的回答Kristopher Johnson的评论。

我会发布的软件质量度量，我能想到的，把我的头，包括顶部的列表：

1. 麦凯布Cyclometric复杂性 - 通过代码线性路径的数量基本措施。
2. 缩进级别 - 查看嵌套决策语句时的复杂度度量。
3. 从声明到首次使用的距离 - 声明变量的位置和首次使用位置之间存在多少声明。
4. 评论百分比 - 与源代码相比，多少行代码是评论。
5. 百分比测试覆盖率 - 作为代码行的百分比，您的测试套件行使了多少。
6. 路径测试覆盖率 - 测试执行多少路径的执行。
7. 单位覆盖率 - 您的单元测试使用多少个单位，类别，包裹等。

克里斯的评论是：

只有在这里列出的测试覆盖指标可以被视为衡量“质量”。其他的是复杂性和可读性的度量，这与质量无关。

除了我完全不同意这个说法，这让我想到了。

当我必须回顾几乎没有任何关联测试的代码时，无论是单元，系统还是集成，我倾向于更接近代码，比如果我看到已成功通过的一整套良好测试更加谨慎。

在对代码执行安全审计时同样的事情。如果我在Apache模块中看到未使用的变量，巨大的函数，奇怪的配置混合，每个服务器，每个目录等等，它也使我非常警惕地接近代码。

是否有其他人使用这种初始的“直觉”方法，并影响结果？

顺便说一句我不同意Kris的评论，因为所有其他指标都是绝对有效的措施，可以帮助突出显示设计不佳，执行不佳的代码。正如达米安康威说：

总是编码，如果最终维护您的代码的人将是一个暴力的精神病患者谁知道你住的地方。

Answer 1

开发的“直觉”是初学者与专业人士的区别。在获得一些经验之后，“直觉”成为最终决定的主要贡献者之一。无论您是在审核某人的代码还是创建系统架构，直觉都会引导您。但务实的开发人员不能太自信。总是有一个检查清单和其他手段的地方。

至于指标，我完全同意你的看法。如果指标无助于代码质量，则指标无意义。

Answer 2

我认为你和克里斯对质量的定义持不同意见。拿数学证明来比喻。

你可能会质疑质量是否正确，是否正确，这是正确的假设从结果。然而，大多数数学家会同意，有些证明比其他证明更好，因为它们更短，更聪明或更容易理解，而这些都是质量的度量。只有第一个定义是可以正式定义的，但是如果他们说“更好的证明”，我认为大多数数学家意味着第二个定义。

克里斯在第一个定义中说的是真实的，只有测试确实测量了正确性，但我认为包括我在内的大多数程序员都会将质量与您的测量关联起来。

Answer 3

是的，只要你有一点经验，“肠道感受”就是一个很好的工具。我似乎记得亨特和托马斯在Pragmatic Programmer中提到过。他们说“你有很多经验，所以不要忽视那种唠叨的感觉”（如果你有正确的引用，或者如果是来自另一本书，请纠正我）。

Carl