函数式编程副作用判定及两类递归整数除法实现合规性分析

核心判定逻辑澄清 #

函数副作用的判定核心，不是函数内部定义了多少局部变量、执行了多少次赋值操作，而是函数执行过程中是否对自身作用域以外的世界产生了可观察的修改。典型的副作用包括：

• 修改全局作用域或外层嵌套作用域的变量
• 修改传入函数的可变对象
• 执行控制台输出、网络请求、文件读写等IO操作
• 抛出未被捕获的异常
• 修改类静态属性、模块级别的可变状态

第一版函数中定义的sign变量，完全不涉及副作用范畴：

• 它的生命周期仅存在于当前函数调用的栈帧内，函数执行结束后就会被回收，不会泄露到外部作用域
• 它的取值完全由当前入参a、b的符号关系推导得到，不存在任何随机或外部依赖
  这类仅在函数内部存在、仅依赖入参计算得到的局部绑定，是纯函数实现中完全允许的部分，和副作用没有关联。

两版实现的规范度对比 #

原始版本代码：

def integer_division(a, b, count=0):
    if (a < 0) ^ (b < 0):
        sign = -1
    else:
        sign = 1

    if abs(a) - abs(b) == 0:
        return (count + 1) * sign
    elif abs(a) - abs(b) < 0:
        return count * sign
    else:
        return integer_division((abs(a) - abs(b))*sign, b, count + 1)

if __name__ == '__main__':
    print(integer_division(-5, 2))
# 输出: -2

改写版本代码：

def integer_division_diff(a, b, count=0, sign=1):
    if (a < 0) ^ (b < 0):
        sign *= -1

    if  abs(a) - abs(b) == 0:
        return (count + 1) * sign
    elif abs(a) - abs(b) < 0:
        return count * sign
    else:
        return integer_division((abs(a) - abs(b)) * sign, b, count + 1)

从函数式编程的核心要求（纯函数、最小参数集、无冗余状态传递）来看，原始版本的实现反而更符合规范：

• 原始版本每一层递归的计算都是自包含的，所有派生值（比如sign）都基于当前层的入参即时计算，没有跨层传递的冗余状态，只要输入确定，输出就完全确定，符合纯函数的核心要求。
• 改写版本的设计初衷，应该是想把sign作为跨递归层传递的状态，避免重复计算符号，但实际实现存在明显的设计冗余：
  1. 参数传递逻辑不完整：递归调用时没有把计算得到的sign值作为实参传入下一层，sign参数始终使用默认值1，所谓的“跨层传递状态”根本没有生效，每一层仍然要靠重新判断a、b的符号关系计算正确值。
  2. 多余的参数设计：sign本身是完全可以从a、b两个入参推导出来的派生值，根本不需要作为独立参数放在函数签名中，这反而增加了函数的接口复杂度，和函数式编程的设计原则相悖。

如果要进一步优化代码的函数式风格，可以把符号计算、差值判断的逻辑抽成独立的纯函数，减少主函数的分支嵌套，让计算流程更清晰。

EDIT： 已修复a为b的整数倍时存在的明显问题。

内容的提问来源于stack exchange，提问作者NotAName