Python的圈复杂度度量标准实践

Question

我有一个相对较大的Python项目，并且没有任何圈复杂性工具作为自动化测试和部署过程的一部分。

Python中的圈复杂度工具有多重要？您或您的项目使用它们并发现它们有效吗？我想要一个很好的前后故事，如果有人的话，那么我们可以从答案中去除一些主观性（即，在我们也没有cyclo-comp工具之前，以及在介绍它之后，好事A发生了，坏事B发生了，等等）。对于这种类型的问题，还有很多其他的一般答案，但是我没有找到特别适合Python项目的答案。

我最终试图确定将它添加到我们的流程中是否值得，以及哪种特定的度量标准和工具/库最适合大型Python项目。我们的主要目标之一是长期维护。

Answer 1

我们在与测试自动化相关的一个项目中使用了RADON工具。

氡

根据新功能和要求，我们需要在该项目中添加/修改/更新/删除代码。另外，几乎有4-5个人正在为此工作。因此，作为审阅过程的一部分，我们确定并使用了RADON工具，因为我们希望我们的代码可维护且可读。

根据RADON工具的输出，有几次我们需要重构代码，添加更多方法并修改循环。

请告诉我这是否对您有用。

Answer 2

wemake-python-styleguide支持圈复杂度的radon和mccabe实现。

还有一些不同的复杂度指标仅包含在循环复杂度中，包括：

• 函数装饰器的数量；越低越好
• 参数数量；越低越好
• 注释数量；越高越好
• 局部变量的数量；越低越好
• 返回、收益、等待的数量；越低越好
• 语句和表达式的数量；越低越好

了解更多关于为什么遵守它们很重要的信息：https ://sobolevn.me/2019/10/complexity-waterfall

它们都被覆盖了wemake-python-styleguide。仓库： https: //github.com/wemake-services/wemake-python-styleguide 文档： https: //wemake-python-stylegui.de

Answer 3

Python 在圈复杂度方面并不特殊。CC 测量一段代码中有多少分支逻辑。

经验表明，当分支“高”时，该代码比分支较低的代码更难理解和可靠地更改。

对于指标来说，重要的通常不是绝对值，而是绝对值。它是您的组织所经历的相对价值。您应该做的是测量各种指标（CC 是其中之一），并在曲线中寻找将该指标与代码中发现的错误相关联的拐点。一旦知道拐点在哪里，就要求编码人员编写复杂性低于拐点的模块。这就是与长期维护的联系。

你无法衡量的东西，你就无法控制。