Python如何实现代码复杂度分析？radon工具

首选radon工具分析python代码复杂度，1. 安装工具：使用pip install radon；2. 分析圈复杂度：运行radon cc 文件或目录，关注cc值超过10或分级为c及以上的代码；3. 分析可维护性指数：运行radon mi 文件或目录，mi低于20需关注，低于10优先重构；4. 集成到ci/cd：在github actions等流程中添加radon检查步骤，设置阈值和排除目录，确保代码质量持续受控，从而有效管理技术债并提升代码可维护性。

Python代码复杂度分析，我通常会首选

radon

解决方案

要用

radon

首先，你得把它装上。这很简单，就像装其他Python包一样：

立即学习“Python免费学习笔记（深入）”；

pip install radon

装好之后，你就可以开始分析了。最常用的就是分析圈复杂度（Cyclomatic Complexity，简称CC）和可维护性指数（Maintainability Index，简称MI）。

比如，你想分析一个名为

my_module.py

分析圈复杂度：

radon cc my_module.py

这会给你一个列表，显示每个函数、方法或类的圈复杂度。圈复杂度越高，代码的逻辑分支就越多，测试起来越麻烦，也越容易出错。我一般会把CC值超过10的函数标记出来，超过20的就得严肃考虑重构了。

分析可维护性指数：

radon mi my_module.py

可维护性指数是一个综合指标，通常在0到100之间。值越高表示代码越容易维护。我通常会把MI值低于20的模块标记出来，这基本上意味着它快变成“遗留代码”了，得优先重构。低于10的，嗯，那可能就是个“烫手山芋”了。

你也可以一次性分析整个项目目录：

radon cc . -a -s -nc # 分析当前目录所有Python文件，显示平均值和总和，不显示颜色
radon mi . -a -s # 分析当前目录所有Python文件，显示平均值和总和

radon

--exclude

--min

--min A

--min B

为什么我们需要关注代码复杂度？

说实话，这个问题我以前也想过，觉得不就是写代码嘛，能跑就行。但后来吃过几次亏，才真正意识到代码复杂度不是个小问题。你想啊，当一个函数有几十个

if-else

关注代码复杂度，实际上是在做风险管理。高复杂度的代码意味着：

代码小浣熊

代码小浣熊是基于商汤大语言模型的软件智能研发助手，覆盖软件需求分析、架构设计、代码编写、软件测试等环节

51

查看详情

• 更高的错误率： 逻辑分支越多，漏掉某个测试用例的可能性就越大，潜在的bug也就越多。
• 更难理解和维护： 新来的同事，甚至过了一段时间的你自己，再看这段代码时，会感到非常吃力。这直接影响了团队的开发效率和项目的迭代速度。
• 测试成本飙升： 要完整覆盖所有逻辑路径，需要的测试用例数量会呈指数级增长。这在敏捷开发里简直是灾难。
• 重构阻力大： 复杂度高的代码往往像一团乱麻，牵一发而动全身，让人望而却步，最终导致技术债越积越多。

所以，我把代码复杂度分析看作是代码质量的“体检报告”。定期检查，能让你及时发现并处理那些潜在的“病灶”，避免它们演变成大问题。

如何解读radon的分析报告？

radon

• 圈复杂度 (CC) 的分级：

  • A (1-5): 优秀的，低风险。
  • B (6-10): 良好的，中等风险。
  • C (11-20): 一般的，高风险，需要关注。
  • D (21-30): 差的，非常高风险，强烈建议重构。
  • E (31-40): 糟糕的，难以维护。
  • F (41+): 极差的，几乎无法维护。

  我通常会把C级及以上的代码作为重点关注对象。当然，有些算法或者状态机，天生圈复杂度就会高一点，这得结合具体业务场景来判断，不能一概而论。但大部分业务逻辑，如果CC值到了D甚至E，那绝对是个警示。

• 可维护性指数 (MI) 的分级：

  • MI > 20: 绿色，易于维护。
  • 10 < MI <= 20: 黄色，中等可维护性。
  • MI <= 10: 红色，低可维护性，需要立即关注。

  MI值是我个人最看重的指标之一。一个低MI的模块，意味着它可能充斥着冗余代码、命名不规范、缺乏注释等问题，这些都会让维护者头疼。我发现把MI值低于10的模块标记出来，这基本上意味着它快变成“遗留代码”了，得优先重构。

除了这两个核心指标，

radon

• LOC (Lines of Code): 代码行数。
• LLOC (Logical Lines of Code): 逻辑代码行数，不包括空行和注释。
• SLOC (Source Lines of Code): 源文件代码行数。
• Halstead Metrics: 包括程序长度、词汇量、难度、工作量等，这些指标能从信息论的角度评估代码的复杂性。虽然不如CC和MI直观，但在某些深层次分析时也很有用。

解读报告时，我不会只看单个数字，而是会结合上下文。比如，一个很小的辅助函数，CC是5，那很棒。但一个核心业务逻辑函数，CC是25，那问题就大了。同时，我也会关注整体项目的平均值和趋势，如果平均复杂度在不断上升，那说明团队在代码质量管理上可能出了问题。

如何将radon集成到持续集成/持续交付（CI/CD）流程中？

将

radon

radon

我发现把

radon

以GitHub Actions为例，你可以在

.github/workflows

code_quality.yml

name: Code Quality Check

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches:
      - main
      - develop

jobs:
  analyze_complexity:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up Python
      uses: actions/setup-python@v5
      with:
        python-version: '3.x'

    - name: Install radon
      run: |
        pip install radon

    - name: Run Radon Cyclomatic Complexity check
      run: |
        # radon cc . --min C --exclude "venv/*,tests/*"
        # 这里我设置了一个比较严格的阈值，任何C级及以上的复杂度都会导致CI失败
        radon cc . --min C --exclude "venv/*,tests/*" --max-cc 10 || { echo "Radon CC check failed: Complexity too high!"; exit 1; }
      continue-on-error: false # 如果失败，则中断流程

    - name: Run Radon Maintainability Index check
      run: |
        # radon mi . --min B --exclude "venv/*,tests/*"
        # 任何B级及以下（MI低于20）的可维护性都会导致CI失败
        radon mi . --min B --exclude "venv/*,tests/*" --min-mi 20 || { echo "Radon MI check failed: Maintainability too low!"; exit 1; }
      continue-on-error: false

在这个例子里，我设置了两个

radon

--min C

--min B

--exclude

venv

tests

当然，一开始集成的时候可能会有好多警告甚至失败，因为现有的代码可能已经积累了一些复杂度。但别灰心，这是改进的机会。你可以先设置一个比较宽松的阈值，比如只检查F级的代码，然后逐步收紧，或者只针对新提交的代码进行检查。关键在于，这是一个持续改进的过程，而不是一次性的完美。

以上就是Python如何实现代码复杂度分析？radon工具的详细内容，更多请关注php中文网其它相关文章！