每个文件的代码行、每个类的方法、圈复杂度等等。开发人员抵制并解决大多数（如果不是全部）！有一篇很好的Joel 文章（现在没时间找到）。
您推荐使用哪些代码指标来自动识别“糟糕的代码”？
什么可以说服大多数开发人员（你不能说服我们所有人接受一些糟糕的指标！：O））这段代码是“垃圾”。
只有可以自动测量的指标才有意义！
Dandikas
问问题
4425 次
27 回答
34
不是自动化解决方案，但我发现 WTF 每分钟有用。
（来源：osnews.com）
于 2008-10-09T13:49:55.030 回答
30
没有关于编码风格的指标是此类警告的一部分。
对我来说，它是关于代码的静态分析，它可以一直“开启”：
我会将覆盖测试放在第二步，因为这样的测试可能需要时间。
不要忘记，“糟糕”的代码不是通过度量来检测的，而是通过度量的组合和演变（如“趋势”中的）来检测的：请参阅代码度量的魅力是什么？问题。
这意味着您不仅要推荐代码指标来“自动识别“糟糕的代码””，还必须推荐正确的组合和趋势分析来遵循这些指标。
在旁注中，我确实分享了您的挫败感；），并且我不同意 tloach 的观点（在另一个答案的评论中）“问一个模糊的问题，得到一个模糊的答案”他说......你的问题值得一个具体的答案。
于 2008-10-09T13:50:13.033 回答
12
我进行构建时编译器发出的警告数。
于 2008-10-09T13:43:07.383 回答
12
每行生产代码的注释行数。通常它表示一个不了解版本控制的草率程序员。
于 2008-10-09T14:18:45.300 回答
9
开发人员总是关心对他们使用的指标，并且调用“蹩脚”代码并不是一个好的开始。这很重要，因为如果您担心您的开发人员在他们周围玩游戏，那么不要将这些指标用于任何对他们有利/不利的事情。
最好的方法是不要让指标告诉您代码在哪里糟糕，而是使用指标来确定您需要查看的位置。您通过代码审查来查看，如何解决问题的决定是在开发人员和审查人员之间。我也会在开发人员方面对指标出错。如果代码仍然在指标上弹出，但审阅者认为它很好，那就别管它了。
但是，当您的指标开始改善时，请务必牢记这种博弈效应。太好了，我现在有 100% 的覆盖率，但是单元测试有什么好处吗？指标告诉我我没问题，但我仍然需要检查一下，看看是什么让我们到达那里。
归根结底，人类胜过机器。
于 2008-10-09T15:24:04.387 回答
8
全局变量的数量。
于 2008-10-09T13:44:12.483 回答
8
不存在的测试（由代码覆盖率显示）。这不一定表明代码不好，但它是一个很大的警告信号。
评论中的脏话。
于 2008-10-09T13:44:43.947 回答
7
单独的指标并不能识别糟糕的代码。但是，他们可以识别可疑代码。
OO 软件有很多指标。其中一些可能非常有用：
- 平均方法大小（在 LOC/语句或复杂性中）。大型方法可能是糟糕设计的标志。
- 被子类覆盖的方法数。较大的数字表示糟糕的类设计。
- 专业化指数（被覆盖的方法数 * 嵌套级别 / 方法总数）。高数字表示类图中可能存在问题。
还有更多可行的指标，可以使用工具进行计算。这可以很好地帮助识别糟糕的代码。
于 2008-10-09T13:54:50.027 回答
6
- 全局变量
- 魔术数字
- 代码/评论比率
- 重耦合（例如，在 C++ 中，您可以通过查看类关系或相互交叉包含的 cpp/头文件的数量来衡量这一点
- 相同代码库中的 const_cast 或其他类型的转换（不带外部库）
- 大部分代码被注释掉并留在里面
于 2008-10-09T14:52:39.693 回答
4
我个人最喜欢的警告标志：评论免费代码。通常意味着编码人员没有停下来思考它；再加上它会自动让人难以理解，所以会增加糟糕的比例。
于 2008-10-09T13:57:20.677 回答
3
我的赌注：圈复杂度 (CC) 和自动化测试 (TC) 的代码覆盖率的组合。
CC | TC
2 | 0% - good anyway, cyclomatic complexity too small
10 | 70% - good
10 | 50% - could be better
10 | 20% - bad
20 | 85% - good
20 | 70% - could be better
20 | 50% - bad
...
crap4j - 可能的工具（用于 java）和概念解释......寻找 C# 友好工具:(
于 2008-10-09T13:43:35.527 回答
3
第一眼：货真价实的成语应用。
仔细一看：程序员的明显错误和误解。
于 2008-10-11T14:33:12.120 回答
2
有意义评论的无价值评论数量：
'Set i to 1'
Dim i as Integer = 1
于 2008-10-09T13:52:00.250 回答
2
我不相信有任何这样的指标。除了实际上没有做它应该做的代码（这是一个额外的糟糕程度）之外，“糟糕”的代码意味着难以维护的代码。这通常意味着维护者很难理解，这在某种程度上总是一个主观的东西，就像糟糕的写作一样。当然，在某些情况下，每个人都同意写作（或代码）很糟糕，但很难为它写一个度量标准。
再加上一切都是相对的。与没有限制的简单函数相比，代码在最小内存中执行高度复杂的函数并针对每个最后一个速度周期进行优化，看起来会非常糟糕。但这并不糟糕——它只是在做它必须做的事情。
于 2008-10-09T13:55:49.807 回答
2
不幸的是，没有我知道的指标。需要记住的是，无论您选择什么，程序员都会对系统进行游戏以使他们的代码看起来不错。我已经看到到处都有任何类型的“自动”指标。
于 2008-10-09T14:13:13.283 回答
2
大量与字符串之间的转换。通常，这表明开发人员不清楚正在发生的事情，只是在尝试随机的事情，直到某些事情起作用。例如，我经常看到这样的代码：
object num = GetABoxedInt();
// long myLong = (long) num; // throws exception
long myLong = Int64.Parse(num.ToString());
当他们真正想要的是：
long myLong = (long)(int)num;
于 2008-10-09T14:42:55.280 回答
2
- 注意模式类与标准类的比率。高比率表示模式炎
- 检查未定义为常量的幻数
- 使用模式匹配实用程序来检测可能重复的代码
于 2008-10-09T15:03:02.450 回答
2
我很惊讶没有人提到crap4j。
于 2008-10-09T15:31:38.927 回答
1
有时，您只是在看到它时就知道它。例如，今天早上我看到：
void mdLicense::SetWindows(bool Option) {
_windows = (Option ? true: false);
}
我只需要问自己“为什么有人会这样做？”。
于 2008-10-09T15:27:26.143 回答
0
代码覆盖率有一定的价值，但除此之外，我倾向于更多地依赖代码分析来判断代码是否糟糕。
于 2008-10-09T13:43:29.880 回答
0
包含亵渎的评论与不包含亵渎的评论的比率。
更高 = 更好的代码。
于 2008-10-09T13:48:43.767 回答
0
注释行/代码行
value > 1 -> bad (too many comments)
value < 0.1 -> bad (not enough comments)
根据您自己的经验调整数值；-)
于 2008-10-09T13:53:34.803 回答
0
我采用多层方法，第一层是合理的可读性，仅由正在解决的问题的复杂性抵消。如果它不能通过可读性测试，我通常认为代码不太好。
于 2008-10-09T14:25:51.277 回答
0
TODO:生产代码中的注释。简单地表明开发人员没有执行任务以完成。
于 2009-11-30T06:42:47.820 回答
0
具有 30 个参数的方法。在网络服务上。就这些。
于 2010-06-23T20:52:47.770 回答
0
好吧，您可以使用多种不同的方法来指出代码是否是好的代码。以下是其中一些：
内聚性：嗯，代码块，无论是类还是方法，如果被发现提供多种功能，那么可以发现代码的内聚性较低。内聚性较低的代码可以称为可重用性较低。这可以进一步称为可维护性较低的代码。
代码复杂度：可以使用 McCabe 圈复杂度（决策点数）来确定代码复杂度。代码复杂度高可用于表示可用性较低（难以阅读和理解）的代码。
文档：从代码可用性的角度来看，没有足够文档的代码也可以归因于软件质量低下。
查看以下页面以了解代码审查清单。
于 2013-02-14T20:28:27.763 回答
-1
这篇关于The Code CRAP Metric 的搞笑博文可能很有用。
于 2009-11-30T04:30:59.303 回答