Python 的圈复杂度度量实践

Cyclomatic complexity metric practices for Python

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

圈复杂度工具在 Python 中有多重要?您或您的项目是否使用它们并发现它们有效?如果有人有故事,我想要一个不错的 before/after 故事,这样我们就可以从答案中去掉一些主观性(即在我们也没有 cyclo-comp 工具之前,以及在我们引入它之后,好事 A 发生了,坏事 B 发生了,等等)。这类问题还有很多其他一般性答案,但我没有找到特别针对 Python 项目的答案。

我最终想决定是否值得将它添加到我们的流程中,以及什么特定指标和 tool/library 最适合大型 Python 项目。我们的主要目标之一是长期维护。

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

经验表明,当分支为 "high" 时,该代码比分支较低的代码更难理解和可靠地更改。

对于度量标准,通常不是绝对值很重要;它是您的组织所经历的相对值。您应该做的是测量各种指标(CC 是一个指标)并在曲线中寻找将指标与代码中发现的错误相关联的拐点。一旦知道拐点在哪里,就要求编码人员编写复杂度低于拐点的模块。这是长期维护的连接。

不衡量,就无法控制。

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

RADON

根据新功能和要求,我们需要在该项目中 add/modify/update/delete 编写代码。此外,几乎有 4-5 个人在为此工作。因此,作为审查过程的一部分,我们确定并使用了 RADON 工具,因为我们希望我们的代码可维护且可读。

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

如果这对你有用,请告诉我。

您还可以使用 mccabe 库。它只计算 McCabe 复杂度,并且可以集成到您的 flake8 linter 中。

wemake-python-styleguide 支持圈复杂度的 radonmccabe 实现。

还有一些不同的复杂度指标没有包含在圈复杂度中,包括:

  • 函数装饰器数量;越低越好
  • 参数个数;越低越好
  • 注释数量;越高越好
  • 局部变量个数;越低越好
  • 数量returns,产量,等待;越低越好
  • 语句和表达式的数量;越低越好

详细了解为什么遵守它们很重要:https://sobolevn.me/2019/10/complexity-waterfall

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