python 指标代码pymetrics 可用于分析代码文件的复杂度。他们创建了两个不同的指标：
McCabe Complexity Metric 用于函数和类COCOMO 2's SLOC Metric 表示整个文件我想知道这些指标的数值是什么意思，而不是真正的定义。 “1”的值是什么意思？数字“5”？数字“10”？更高更好还是更低？什么数值代表好代码，什么代表真正糟糕的代码？搜索互联网给出了一些hints，但我不确定分类是指公制（1）还是公制（2）。我想对这两个数字都有意义。
【问题讨论】：
我认为您的问题中有一个有问题的假设，即好的代码对于某个指标具有一定的价值。您无法用单一指标真正衡量代码的质量，它是多种事物的组合，并且高度依赖于上下文。真正超级高效的代码通常有点难以理解，这会是糟糕的代码吗？
IBM 决定在 70 年代通过他们生成的代码行数 (SLOC) 来衡量他们的程序员的质量。不用说，这导致了一些非常冗长和愚蠢的代码。
如果您想了解代码的质量，那么您需要其他开发人员来查看它。最好是比您更有经验的开发人员。友好的代码审查非常适合学习，它还会迫使你思考为什么你会按照自己的方式做某事，而不是其他本可以完成的方式。幸运的是，stackexchange 正好提供了that。
来自维基百科
圈复杂度（或条件复杂度）是一种软件度量 （测量）。它由 Thomas J. McCabe, Sr. 于 1976 年开发， 用于表示程序的复杂性。它直接测量 通过程序源的线性独立路径的数量 代码。这个概念，虽然不是方法，但有点类似于 由 Flesch-Kincaid 测量的一般文本复杂度 可读性测试。 ... 一段源代码的圈复杂度是通过源代码的线性独立路径的数量的计数。例如，如果源代码不包含诸如 IF 语句或 FOR 循环之类的决策点，复杂度将为 1，因为通过代码只有一条路径。如果代码有一个包含单个条件的 IF 语句，则将有两条路径通过代码，一条 IF 语句被评估为 TRUE 的路径和一个 IF 语句被评估为 FALSE 的路径。
你不能说1 比2 更好，这取决于上下文（你在写什么语言，谁在写代码等等）。您应该将圈复杂度值视为提示您理解代码的控制流 是多么容易。大量嵌套的if 语句会导致高CC。因此，理想情况下，您的 CC 为 1（可能是每个函数），即一个函数以一种方式做一件事，没有别的，但显然这并不总是可能的。您必须在上下文中评估您为该指标获得的任何值。
您倾向于在用相同语言编写的其他库中看到什么样的价值观？不过，我不能给你一个数字（对不起）。我可以说 15 的 CC 值可能有点过头了，应该重构代码。这是执行脚本/函数的 15 种不同方式。在您的测试中需要考虑 15 种不同的条件该功能，并且不要忘记所有可能使这 15 件事不起作用的因素。你需要对它们进行另一个单元测试，以及值的组合（你明白了）。
源代码行 (SLOC) 是一种软件指标，用于衡量 通过计算文本中的行数来计算计算机程序的大小 该程序的源代码。 SLOC 通常用于预测 开发程序所需的工作量，以及 估计编程生产力或可维护性一旦 软件制作完成。
建设性成本模型 (COCOMO) 是一种算法软件成本 Barry W. Boehm 开发的估计模型。该模型使用基本 具有从历史导出的参数的回归公式 项目数据和当前项目特征。
另一方面，COCOMO 并没有真正衡量代码的质量，它是一种软件项目成本计算模型 (COCOMO II)，是对最近（90 年代后）软件项目的更新。
COCOMO II 实际上是三种不同的型号：
• 应用程序组合模型 - 适用于使用现代 GUI 构建器工具构建的项目。基于新的对象点。
• 早期设计模型 - 在确定项目的整个架构之前，您可以使用此模型粗略估算项目的成本和持续时间。它使用一小组新的成本动因和新的估算方程。基于未调整的功能点或KSLOC。
• 后架构模型 - 这是最详细的 COCOMO II 模型。您将在开发项目的整体架构后使用它。它有新的成本 驱动程序、新的行计数规则和新的方程式。
功能点是一个功能单元，KSLOC是数千行代码。所以 COCOMO 模型是为了估计软件项目的成本、时间、所需资源等，而不是评估代码的质量。
【讨论】：
COCOMO 2's SLOC 的数字的输出，既不是 COCOMO 也不是 SLOC，但还有别的，我不知道！另外，当我在情况（1）中得到数字 1 时，它是好是坏？ 5号？一个数字 100？情况（2）呢？
COCOMO 2 是COCOMO 的更新，其中一部分是SLOC 指标。如果您想知道指标值的比例，那么您应该问这个（尽管这也可以在维基百科中找到），而不是指标的含义。