软件复杂度：那些让代码变得难以理解的东西，到底能不能量化？

写代码的人大概都有过这种体验，某个函数刚开始只有十几行，逻辑清晰得像说明书，可是半年之后再打开它，已经变成一坨嵌套了七八层if-else、夹杂着各种历史遗留判断的迷宫。这种从简单到复杂的滑坡过程，正是软件工程里一直想要解决的核心问题——软件复杂度。

这篇文章要聊清楚几件事：软件复杂度到底指什么，业界有哪些成熟的度量方法，这些方法背后的数学逻辑是什么样的，以及用Python怎么实际计算出这些指标。

软件复杂度究竟是什么

软件复杂度不是一个模糊的感觉，而是可以从多个维度拆解的概念。它大致可以分成两类，一类是结构复杂度，关注代码的控制流有多少分支、多少路径；另一类是认知复杂度，关注人脑在理解这段代码时需要付出多少心智努力。

举个例子，一个包含十个并列if语句的函数，和一个嵌套了十层if的函数，虽然在传统的分支计数上可能得分相近，但后者对人类阅读者的负担要重得多。这也是为什么后来会出现专门针对"人类理解难度"设计的度量方式，而不是单纯统计分支数量。

软件复杂度高会带来什么后果？答案很直接：出问题的概率更高，修复起来更费劲，新人接手的成本也更大。所以度量复杂度，本质上是在给代码的可维护性和潜在风险提前打分。

度量体系一：圈复杂度，最经典的结构化指标

概念来源

圈复杂度（Cyclomatic Complexity）由Thomas J. McCabe在1976年提出，是软件度量领域最古老也是应用最广泛的指标之一。它的数学基础来自图论，把程序的控制流看作一张有向图，节点代表代码块，边代表控制流转移。

McCabe给出的计算公式很简洁：

$V(G)=E-N+2P$

其中E是图中边的数量，N是节点数量，P是连通分量的个数（对单个函数来说通常是1）。

在实际编程中，更常用的简化理解是：圈复杂度等于程序中判断节点（if、for、while、case等）的数量加一。每多一个分支判断，代码的路径数量就多一条，理解和测试它所需要覆盖的场景也就多一个。

Python示例

假设有这样一个简单的折扣计算函数：

 复制代码def calculate_discount(price, is_vip, has_coupon, order_count):
    if is_vip:
        if has_coupon:
            discount = 0.7
        else:
            discount = 0.8
    else:
        if order_count > 10:
            discount = 0.9
        elif has_coupon:
            discount = 0.95
        else:
            discount = 1.0
    return price * discount

手动数一下判断点：is_vip、has_coupon（第一层）、order_count > 10、elif has_coupon（第二层），一共4个判断，圈复杂度就是4+1=5。这意味着测试这个函数至少需要设计5条独立的路径才能做到完整覆盖。

用工具自动计算会更靠谱，Python生态里最常用的是radon库：

 复制代码from radon.complexity import cc_visitcode = """
def calculate_discount(price, is_vip, has_coupon, order_count):
    if is_vip:
        if has_coupon:
            discount = 0.7
        else:
            discount = 0.8
    else:
        if order_count > 10:
            discount = 0.9
        elif has_coupon:
            discount = 0.95
        else:
            discount = 1.0
    return price * discount
"""results = cc_visit(code)
for item in results:
    print(f"函数名: {item.name}, 圈复杂度: {item.complexity}")

输出结果会显示复杂度为5，跟手工推算一致。业界一般把圈复杂度10以内视为健康区间，超过20就属于高风险代码，需要考虑拆分重构。

度量体系二：Halstead复杂度，从代码的词汇量入手

概念来源

如果说圈复杂度关注的是控制流的分支结构，那Maurice Halstead在1977年提出的这套指标关注的是另一个维度：代码里用了多少不同的运算符和操作数，出现的总次数又是多少。

这个思路有点像统计学里分析一篇文章的用词丰富度——词汇量越大、重复使用的次数越多，理解这篇文章需要的脑力负担通常也越大。

Halstead定义了几个基础变量：

• $n_1$，不同运算符的数量（比如+、-、if、for）
• $n_2$，不同操作数的数量（比如变量名、常量）
• $N_1$，运算符出现的总次数
• $N_2$，操作数出现的总次数

基于这四个数字，可以推导出一系列指标，比如程序词汇量$n=n_1+n_2$，程序长度$N=N_1+N_2$，以及最重要的程序体积（Volume）：

$V=N\times {\log }_2(n)$

体积越大，代表程序包含的信息量越多，理解成本也就越高。

Python示例

手动计算Halstead指标比较繁琐，实际项目中直接用radon库：

 复制代码from radon.metrics import h_visitcode = """
def calculate_discount(price, is_vip, has_coupon, order_count):
    if is_vip:
        if has_coupon:
            discount = 0.7
        else:
            discount = 0.8
    else:
        if order_count > 10:
            discount = 0.9
        elif has_coupon:
            discount = 0.95
        else:
            discount = 1.0
    return price * discount
"""result = h_visit(code)
print(f"词汇量(n): {result.total.vocabulary}")
print(f"长度(N): {result.total.length}")
print(f"体积(Volume): {result.total.volume:.2f}")
print(f"难度(Difficulty): {result.total.difficulty:.2f}")
print(f"工作量(Effort): {result.total.effort:.2f}")

这里的难度（Difficulty）反映了代码出错的可能性，工作量（Effort）则可以粗略估算理解或编写这段代码需要花费的脑力时间。Halstead甚至给出过一个换算公式，把Effort除以18就能得到大概需要的秒数。虽然这个换算在现代开发环境下已经不太准确，但作为相对比较的指标依然有参考价值。

度量体系三：可维护性指数，把多个指标揉在一起

单看圈复杂度或者单看Halstead体积，都只能反映问题的一个侧面。所以后来微软等团队提出了可维护性指数（Maintainability Index），试图把代码行数、圈复杂度、Halstead体积综合成一个0到100的分数。

标准公式是这样的：

$MI=171-5.2\ln (V)-0.23G-16.2\ln (L)$

这里V是Halstead体积，G是圈复杂度，L是代码行数。微软在Visual Studio里用的是归一化版本，把结果压缩到0-100之间，方便直观判断。

分数越高代表代码越容易维护，一般来说85以上是绿灯区，20到85是黄灯区需要关注，低于20则是红灯区，意味着这段代码可能已经难以维护。

Python示例

 复制代码from radon.metrics import mi_visitcode = """
def calculate_discount(price, is_vip, has_coupon, order_count):
    if is_vip:
        if has_coupon:
            discount = 0.7
        else:
            discount = 0.8
    else:
        if order_count > 10:
            discount = 0.9
        elif has_coupon:
            discount = 0.95
        else:
            discount = 1.0
    return price * discount
"""mi_score = mi_visit(code, multi=True)
print(f"可维护性指数: {mi_score:.2f}")

这个分数会随着代码行数增加、分支变多、变量命名混乱而下降，是一个很适合放进CI流程里做质量门禁的综合指标。

度量体系四：认知复杂度，更贴近人类真实感受的新思路

传统的圈复杂度有个明显短板：它对代码的嵌套深度不敏感。一个扁平的、有五个并列if的函数，和一个嵌套了五层if的函数，圈复杂度算出来可能一样，但后者读起来明显更费劲。

SonarSource团队在2017年提出了认知复杂度（Cognitive Complexity）这个指标，专门针对这个问题做了改进。它的核心思路是给每一层嵌套增加额外的惩罚分数，逻辑越深，惩罚越重，同时对于顺序的逻辑运算符（比如连续的&&）也会累加分数，因为这些都会增加人脑的解析负担。

下面用一张图来说明圈复杂度和认知复杂度看待代码的不同视角：

目前认知复杂度还没有像圈复杂度那样成为Python标准库的一部分，但SonarQube等静态分析工具已经内置了这个指标，可以直接在CI流程里获取报告。

几种度量方式的横向对比

不同的度量指标各有侧重，实际项目中通常不会只用一种，而是组合起来交叉验证。

从表格能看出一个趋势：度量体系是在不断进化的，从最早只关注路径数量的圈复杂度，到综合多维数据的可维护性指数，再到贴近人类认知规律的认知复杂度，每一次迭代都是在弥补前一代指标的盲区。

实战建议，怎么把这些指标用起来

知道这些指标怎么算只是第一步，真正有价值的是把它们嵌入日常开发流程。radon这个Python库基本能覆盖前三种指标的计算需求，安装方式很简单：

 复制代码pip install radon

然后可以直接对整个项目跑批量分析：

 复制代码radon cc your_project/ -a -s  # 圈复杂度，带平均值和详细信息
radon mi your_project/ -s     # 可维护性指数
radon hal your_project/       # Halstead指标

对于追求更精细认知复杂度分析的团队，可以考虑接入SonarQube这类静态分析平台，它会在代码评审阶段自动标记出复杂度超标的函数，逼着开发者在提交代码前就做拆分和重构。

写在最后

软件复杂度这件事，说到底是在给"代码有多难被人理解"这个主观感受找一把可以量化的尺子。从McCabe的图论方法，到Halstead的信息论视角，再到融合多指标的可维护性分数，最后到贴近认知科学的认知复杂度，这条演进路线其实也反映了软件工程本身的成熟过程——从只关心机器怎么执行，逐渐过渡到关心人怎么理解和维护。

对于日常开发来说，没必要纠结哪个指标才是唯一真理，更实际的做法是把圈复杂度和认知复杂度设成CI流程里的硬性门槛，把可维护性指数当作长期趋势的健康检查表。工具帮你算出数字之后，真正决定代码质量的，还是拿到这些数字之后你愿不愿意花时间去拆解那些复杂到超标的函数。

参考资料

Cyclomatic complexity，Wikipedia，en.wikipedia.org/wiki/Cyclom…

Cyclomatic Complexity Guide，SonarSource，www.sonarsource.com/resources/l…

A Complexity Measure（McCabe原始论文），literateprogramming.com，www.literateprogramming.com/mccabe.pdf

Halstead complexity measures，Wikipedia，en.wikipedia.org/wiki/Halste…

Software Engineering - Halstead's Software Metrics，GeeksforGeeks，www.geeksforgeeks.org/software-en…

Code metrics - Maintainability index range and meaning，Microsoft Learn，learn.microsoft.com/en-us/visua…

Introduction to Code Metrics，Radon Documentation，radon.readthedocs.io/en/latest/i…

Cognitive Complexity，SonarSource，www.sonarsource.com/resources/c…