什么代码指标说服您提供代码是"糟糕"？

Question

每个文件的代码行,每个类的方法,圈复杂度等.开发人员抵制并解决大多数(如果不是全部的话)!有一篇很好的Joel文章(没时间找到它).

您建议使用哪些代码指标来自动识别"糟糕的代码"？

什么可以说服大多数(你不能说服我们所有人一些糟糕的指标!:O))开发人员认为这个代码是"废话".

只有可自动测量的指标才算重要!

Answer 1

不是自动化解决方案,但我发现WTF每分钟有用.

_{(来源:osnews.com)}

Answer 2

没有关于编码风格的指标是这种警告的一部分.

对我来说,它是关于代码的静态分析,它可以一直"开启":

我会在第二步进行覆盖测试,因为这样的测试需要时间.

不要忘记指标不会检测到"糟糕"代码,而是通过指标的组合和演变(如" 趋势"):请参阅代码指标的含义是什么？问题.

这意味着您不必仅推荐代码指标来"自动识别"糟糕的代码"",但您还必须建议正确的组合和趋势分析来遵循这些指标.

在旁注中,我确实分享了你的挫折感 ;),我不同意tloach的观点(在另一个答案的评论中)"提出一个模糊的问题,得到一个模糊的答案"他说......你的问题值得一个具体的答案.

Answer 3

编译时编译器吐出的警告数.

Answer 4

每行生产代码注释掉的行数.通常它表示一个不懂版本控制的邋program程序员.

Answer 5

开发人员总是关注对他们使用的度量标准,并且调用"糟糕"的代码并不是一个好的开始.这很重要,因为如果您担心开发人员围绕他们进行游戏,那么请不要将指标用于任何对他们有利/不利的事情.

这种方法效果最好的方法是不要让指标告诉您代码蹩脚的位置,而是使用指标来确定您需要查看的位置.您可以通过代码审查来查看,并且在开发人员和审阅者之间决定如何解决问题.我也会因开发人员违反指标而出错.如果代码仍然存在于度量标准上,但审阅者认为它是好的,请不要管它.

但是,当您的指标开始改善时,请务必牢记这种游戏效果.太好了,我现在有100%的覆盖率,但单位测试有什么好处？该指标告诉我我很好,但我仍然需要检查它,看看是什么让我们在那里.

最重要的是,人类胜过机器.

Answer 6

全局变量的数量.

Answer 7

亵渎通常意味着一个程序员在另一个程序员咒骂 - 可能在另一个项目上.这可能意味着他们必须在同一个模块中修复糟糕的代码,或者他们必须在其他地方解决bug.无论哪种方式值得了解. (6认同)

Answer 8

单独的度量标准不能识别糟糕的代码.但是,他们可以识别可疑代码.

OO软件有很多指标.其中一些非常有用:

有更多可行的指标,可以使用工具计算它们.这可以很好地帮助识别糟糕的代码.

Answer 9