为什么全局变量是邪恶的？

问题描述：

我试图找出为什么该global关键字在 Python（以及一般编程）中被视为不良做法。有人能解释一下吗？如果有更多信息的链接也非常感谢。

解决方案 1：

这与 Python 无关；在任何编程语言中，全局变量都是不好的。

但是，全局常量在概念上与全局变量不同；全局常量完全无害。在 Python 中，两者之间的区别纯粹是惯例：CONSTANTS_ARE_CAPITALIZED和globals_are_not。

全局变量不好的原因是它们使函数产生隐藏的（不明显、令人惊讶、难以检测、难以诊断）副作用，从而导致复杂性增加，有可能导致意大利面条式代码。

然而，即使在函数式编程中，合理使用全局状态（本地状态和可变性也是如此）也是可以接受的，无论是为了算法优化、降低复杂性、缓存和记忆，还是为了移植源自以命令式为主的代码库的结构的实用性。

总而言之，您的问题可以通过多种方式回答，因此最好的办法是谷歌搜索“为什么全局变量不好”。以下是一些示例：

• 全局变量不好 - Wiki Wiki Web

• 为何全局状态如此邪恶？ - 软件工程 Stack Exchange

• 全局变量不好吗？

如果你想更深入地了解副作用的原因以及许多其他有启发性的事情，你应该学习函数式编程：

• 副作用（计算机科学） - 维基百科

• 为什么在函数式编程中副作用被认为是邪恶的？ - 软件工程 Stack Exchange

• 函数式编程 - 维基百科

解决方案 2：

是的，从理论上讲，全局变量（以及一般意义上的“状态”）是邪恶的。实际上，如果你查看 Python 的包目录，你会发现那里的大多数模块都以一堆全局声明开头。显然，人们对此没有意见。

具体来说，对于 Python，全局变量的可见性仅限于模块，因此不存在影响整个程序的“真正”全局变量 - 这使得它们的危害更小。另一点：没有const，所以当你需要一个常量时，你必须使用全局变量。

在我的实践中，如果我碰巧修改了函数中的全局变量，我总是用 声明它global，即使技术上没有必要这样做，如下所示：

cache = {}

def foo(args):
    global cache

    cache[args] = ...

这使得全局变量的操作更容易被追踪。

解决方案 3：

关于这个主题的个人观点是，在函数逻辑中使用全局变量意味着其他一些代码可以改变该函数的逻辑和预期输出，这将使调试变得非常困难（特别是在大型项目中），并且也会使测试变得更加困难。

此外，如果您考虑让其他人阅读您的代码（开源社区、同事等），他们将很难理解全局变量在哪里设置、在哪里发生了更改以及对这个全局变量的期望是什么，而不是像一个独立的函数那样可以通过阅读函数定义本身来确定其功能。

（可能）违反纯函数定义

我认为干净且（几乎）无错误的代码应该具有尽可能纯净的函数（请参阅纯函数）。纯函数是具有以下条件的函数：

1. 给定相同的参数值，函数总是计算相同的结果值。函数结果值不能依赖于程序执行过程中或程序不同执行之间可能发生变化的任何隐藏信息或状态，也不能依赖于来自 I/O 设备的任何外部输入（通常——见下文）。

2. 对结果的评估不会导致任何语义上可观察的副作用或输出，例如可变对象的变异或输出到 I/O 设备。

拥有全局变量至少会违反上述其中一项，如果不是同时违反两项的话，因为外部代码可能会导致意外的结果。

纯函数的另一个明确定义是：“纯函数是将所有输入作为显式参数并将其所有输出作为显式结果的函数。” [1]。全局变量违反了纯函数的理念，因为输入和输出之一（全局变量）并未明确给出或返回。

（可能）违反单元测试第一原则

进一步说，如果你考虑单元测试和 FIRST 原则（快速测试、独立测试、可重复、自我验证和及时）可能会违反独立测试原则（这意味着测试不相互依赖）。

拥有全局变量（并非总是如此）但在大多数情况下（至少就我目前所见而言）是为了准备并将结果传递给其他函数。这也违反了这一原则。如果以这种方式使用全局变量（即必须先在函数 Y 中设置函数 X 中使用的全局变量），则意味着要对函数 X 进行单元测试，您必须先运行测试/运行函数 Y。

全局变量作为常量

另一方面，正如其他人已经提到的那样，如果将全局变量用作“常量”变量可能会更好一些，因为该语言不支持常量。但是，我总是更喜欢使用类并将“常量”作为类成员，而根本不使用全局变量。如果您有两个不同的类需要共享一个全局变量的代码，那么您可能需要重构您的解决方案并使您的类独立。

我不认为不应该使用全局变量。但如果使用全局变量，作者应该考虑一些原则（可能是上面提到的原则以及其他软件工程原则和良好实践），以获得更干净、几乎无错误的代码。

解决方案 4：

它们是必不可少的，屏幕就是一个很好的例子。然而，在多线程环境中或涉及许多开发人员的情况下，在实践中经常会出现这样的问题：谁（错误地）设置或清除了它？根据架构，分析可能很昂贵并且经常需要。虽然读取全局变量是可以的，但必须控制写入，例如通过单个线程或线程安全类。因此，全局变量会引起高昂的开发成本，因为其本身被认为是邪恶的后果。因此，一般来说，保持全局变量的数量较少是一种很好的做法。