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

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

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

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

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

1> Tom Ritter..：

---

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

_{(来源:osnews.com)}

---

您可以使用评论员在代码审查期间按下的WTF按钮自动执行此操作:或者非常好的语音识别软件.

---

对不起,我真的对自动解决方案很感兴趣...我知道这是最好的,不是自动化的.

2> VonC..：

---

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

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

圈复杂度(由checkstyle检测)

依赖循环检测(例如通过findbugs)

检测到的严重错误,例如findbugs.

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

---

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

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

---

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

3> tloach..：

---

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

4> polara..：

---

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

5> Flory..：

---

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

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

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

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

6> tloach..：

---

全局变量的数量.

---

我以为他们和恐龙一起出去了......

7> Jon Skeet..：

---

不存在的测试(由代码覆盖率揭示).它不一定表示代码是坏的,但它是一个很大的警告信号.

评论亵渎.

---

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

8> Toon Krijthe..：

---

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

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

平均方法大小(LOC /语句或复杂性).大型方法可能是糟糕设计的标志.

由子类重写的方法数.大量数字表示糟糕的课程设计.

专业化指数(被覆盖的方法数*嵌套级别/方法总数).高数字表示类图中可能存在的问题.

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

9> Milan Babušk..：

---

全局变量

神奇的数字

代码/评论比率

重耦合(例如,在C++中,您可以通过查看类关系或相互交叉包含的cpp /头文件的数量来衡量这一点

const_cast或其他类型的转换在相同的代码库内(不是外部库)

大部分代码被注释掉并留在那里