在一天结束时，你的程序或应用程序仍然可以工作，但这是一个整洁的问题，并对正在发生的事情有一个完整的理解。如果在所有函数之间共享一个变量值，那么可能很难跟踪是哪个函数更改了该值(如果函数更改了该值)，这将使调试变得更加困难

全局变量的问题是，由于每个函数都可以访问这些变量，因此越来越难以确定哪些函数实际读写这些变量。

为了理解应用程序是如何工作的，您几乎必须考虑修改全局状态的每个函数。这是可以做到的，但随着应用程序的增长，它将变得越来越困难，几乎不可能(或至少完全浪费时间)。

如果不依赖全局变量，则可以根据需要在不同函数之间传递状态。这样，您就有更好的机会理解每个函数的功能，因为您不需要考虑全局状态。

全局变量在小程序中很好，但如果在大程序中以同样的方式使用就很糟糕了。

这意味着你可以很容易地在学习中养成使用它们的习惯。这就是你的教授想要保护你的东西。

当你更有经验的时候，在他们没事的时候学习就更容易了。

重要的是要记住总体目标:清晰

“无全局变量”规则的存在是因为大多数时候，全局变量使代码的含义不太清楚。

然而，像许多规则一样，人们记住的是规则，而不是规则的意图。

我曾经见过一些程序，为了避免全局变量的危害，通过传递大量参数，使代码的大小增加了一倍。最后，使用全局变量将使程序对阅读它的人更清楚。由于盲目地遵守规则的文字，原来的程序员未能实现规则的意图。

所以，是的，全局变量通常不好。但是如果你觉得在最后，程序员的意图通过使用全局变量变得更加清晰，那么就继续吧。但是，请记住，当您强迫某人访问第二段代码(全局代码)以理解第一部分是如何工作的时，清晰度会自动下降。

使用全局变量有点像扫地毯下的灰尘。这是一种快速的解决方法，在短期内比用吸尘盆或吸尘器清理要容易得多。然而，如果你后来搬了地毯，下面会有一个大的惊喜。

当涉及到配置时，全局是很好的。当我们希望我们的配置/更改对整个项目产生全局影响时。

因此，我们可以改变一个配置，并将更改指向整个项目。但我必须警告你，你必须非常聪明地使用全局变量。