functional-programming - 参考透明度/功能纯度是最佳实践还是取决于偏好？

Question

我想知道对于功能纯度是否被认为是最佳实践或者它是否取决于偏好或编程风格是否存在共识。换句话说，这是有争议的，还是有效地确定了？我能找到的所有信息都表明这是一种没有缺点的美德。这是真的？

我想为我们当地的实践社区编制一份最佳实践列表，并且我想知道应该在多大程度上包含这些实践。

score 4 · Accepted Answer

最好避免突变和其他副作用，就像最好避免 goto 一样。也就是说，在某些情况下它是有用的，但更多时候不是它可以被消除并被更结构化的解决方案所取代，而不会有太大的困难。

当然，这在很大程度上取决于您使用的语言和库。无副作用编程在不是为它设计的语言（即几乎所有主流语言）中非常不方便。

独立于特定的语言约束，也可能存在在不改变 big-O 复杂性类的情况下难以用函数式替代的可变数据结构或命令式算法的情况。在大多数相关案例中，现在都知道好的解决方案，但有时它们很棘手，在某些情况下，需要积极研究。

话虽如此，你可以在不失去纯度的情况下产生副作用。参见例如 Haskell 对 monad 的使用。

score 3 · Accepted Answer

作为一般规则，您应该减少代码中的无意复杂性。这是无可争议的。

降低复杂性的最佳方法之一是限制代码中的信息通道——信息可以从一个组件“泄漏”到另一个组件的方式。这使您的代码更简单、更模块化、更易于测试、更易于使用和更易于维护。

根据定义，可变变量和其他副作用是信息通道，与通常的函数参数和结果通道相比，这些通道相对“隐藏”。带有它们的代码就像一个筛子，信息通过可变变量以瞬态的、时间相关的方式泄漏进出代码。

全局可见的可变变量是最糟糕的，因为它们（可能）在整个代码库中泄漏信息，从而增加了许多需要管理的复杂信息通道。局部范围的可变变量最多只泄漏几行的时间信息。你应该避免前者，小心后者。

因此，在最小化复杂性和增加模块化的目标中，您应该避免泄漏的副作用，因为它们会以不必要的复杂性污染您的代码。避免可变变量和其他副作用是一个很好的经验法则。

2 回答 2