我想知道，对于功能纯度是否被视为最佳实践，或者是否取决于偏好或编程风格，是否达成了共识。换言之，这是否值得讨论，或者这是否是有效确定的？我所能找到的所有信息都表明，这是一种没有缺点的美德。这是真的吗？
我想为我们当地的实践社区编制一份最佳实践清单，我想知道这应该在多大程度上包括在内。
最好避免突变和其他副作用，就像最好避免goto一样。也就是说，在某些情况下它是有用的，但通常情况下，它可以被消除，并被更结构化的解决方案取代，而不会遇到太多困难。
当然，这在很大程度上取决于您使用的语言和库。无副作用编程在非为其设计的语言(即几乎所有主流语言)中非常不方便。
独立于特定的语言约束，也可能存在可变数据结构或命令式算法的情况，在不改变big-O复杂性类的情况下，这些数据结构或算法很难被函数式算法替代。在大多数相关的情况下，目前已经知道了好的解决方案，但有时它们很棘手，在某些情况下，还需要积极的研究。
话虽如此，但你很可能会有副作用而不会失去纯度。参见Haskell对monad的使用。
作为一般规则，您应该减少代码中的非故意复杂性。这是没有争议的。
降低复杂性的最佳方法之一是限制代码中的信息通道，即信息从一个组件"泄漏"到另一个组件的方式。这使您的代码更简单、更模块化、更易于测试、更易于使用和更易于维护。
根据定义，可变变量和其他副作用是信息渠道，与函数自变量和结果的通常渠道相比，这些渠道相对"隐藏"。有了它们的代码就像一个筛子，信息通过可变变量以瞬态的、时间相关的方式泄漏到代码中。
全局可见的可变变量是最糟糕的，因为它们(可能)会在整个代码库中泄漏信息，从而增加许多需要管理的复杂信息通道。局部作用域的可变变量最多只泄漏几行的时间信息。你应该避免前者，小心后者。
因此，为了最大限度地降低复杂性和提高模块性，您应该避免泄漏的副作用，因为它们会以不必要的复杂性污染您的代码。避开可变变量和其他副作用是一条很好的经验法则。