WPS221规则在f-strings场景下的Jones复杂度计算问题分析

问题背景

在wemake-python-styleguide项目中，WPS221规则用于检测代码行的Jones复杂度。Jones复杂度是一种衡量代码行认知复杂度的指标，当某行代码的复杂度超过14时就会触发警告。最近发现该规则在处理包含多个self属性访问的f-strings时过于严格。

问题重现

考虑以下典型场景：一个Token类需要实现__str__方法，使用f-string格式化输出多个属性：

@frozen
class Token:
    def __str__(self):
        return f"{self.type}:{self.lexeme}:{self.line}:{self.char}"

WPS221规则会报告这行代码的Jones复杂度为17（超过阈值14），但实际上这种f-string的认知复杂度并不高。

技术分析

通过AST分析可以发现，f-string会被解析为包含多个FormattedValue节点的JoinedStr结构。当前的Jones复杂度计算将这些节点都计入复杂度，导致总和偏高。

从认知复杂度角度看：

1. f-string本身是一种直观的字符串格式化方式
2. self.attr形式的属性访问与直接变量访问的认知负担相近
3. 多个属性访问以冒号分隔的结构非常直观

解决方案探讨

经过讨论，提出了几种可能的改进方向：

1. 忽略特定AST节点：在计算复杂度时，可以忽略JoinedStr和FormattedValue节点本身，只计算其子节点。这样能降低f-string的结构带来的复杂度，同时保留内容部分的复杂度计算。

2. 调整属性访问权重：可以区分self.attr和其他形式的属性访问，给予前者较低的权重。不过这种方法可能引入过多主观判断。

3. 特殊处理f-string：针对f-string场景设计专门的复杂度计算规则，考虑其语法特性。

最终倾向于第一种方案，因为它：

• 保持规则的简单性
• 不引入过多特殊情况处理
• 更符合实际认知复杂度

实现建议

在Jones复杂度计算器中，可以修改节点遍历逻辑，对f-string相关节点进行特殊处理：

def _count_nodes(node):
    if isinstance(node, (ast.JoinedStr, ast.FormattedValue)):
        return sum(_count_nodes(child) for child in ast.iter_child_nodes(node))
    # 原有其他节点处理逻辑

这种修改能更准确地反映代码的实际认知复杂度，避免对f-string格式化的误判。

总结

代码质量工具需要在严格性和实用性之间取得平衡。对于wemake-python-styleguide这样的项目，理解各种语法结构的实际认知复杂度非常重要。通过优化AST节点的处理方式，可以使Jones复杂度规则更加精准，减少误报，提升开发者体验。