最近有读者遇到了这样的问题：

入职接到前同事丢下的“烂摊子”，项目中很多全局变量······

问我：全局变量太多有哪些弊端？该如何规避，以及如何管理全局变量等。

全局变量太多有哪些弊端？

真正做过项目的同学应该都能明白，项目中全局变量太多，会存在很多问题。

这里给大家罗列一些太多全局变量可能存在的弊端：

1、代码可读性差

漫天全局变量，特别是各个源文件都有全部变量的情况下，代码可读性相信你都能明白有多差。

如果再加上命名不规范、随处定义，代码可读性更是不能言语。

2、代码维护难度大

随着全局变量的增多，不同模块的变量名可能会产生冲突或混淆，导致代码难以理解和维护。同时，全局变量使得代码中的依赖关系变得复杂，难以追踪和理解。这增加了新开发人员的学习成本，也增加了修改和调试的难度。

3、可移植性差

全局变量通常与特定的硬件或系统配置紧密相关，各个文件都在调用全局变量，这使得代码的可移植性很差。

再次就是，随着项目的增长和功能的增加，全局变量的管理和维护变得更加困难，这限制了项目的可扩展性。

4、内存管理问题

全局变量太多会导致内存泄漏，以及碎片等诸多问题。

内存泄漏：如果没有适当地管理全局变量的生命周期，可能会导致内存泄漏，特别是在资源受限的单片机环境中。

内存碎片：频繁地分配和释放全局变量相关的内存可能导致内存碎片，降低内存利用效率。

5、潜在bug

随着全局变量的增多，出现bug的概率越大，多个函数或模块可能同时访问和修改全局变量，如果没有适当的同步机制，会导致数据不一致和难以预测的行为。

一个函数对全局变量的修改可能会影响到其他不相关的函数，这种隐式的副作用使得错误难以定位和修复。

6、不利于模块化设计

如果全局变量在各个模块中穿插使用，不仅破坏了模块的独立性，还使得模块之间的耦合度增加，降低了代码的可重用性和可维护性。

通常来说，模块化设计的代码，不会存在全局变量，或者很少有全局变量。

7、增加调试难度

在单元测试测试，或项目全局测试时，全局变量的状态管理变得复杂。测试人员需要确保在每次测试之前全局变量处于正确的状态。如果全局变量的修改可能发生在代码的多个位置，这使得调试时难以确定问题的根源。

8、更多弊端

以上是常见的弊端，还有哪些弊端，大家可以留言讨论。

全局变量太多如何规避？

全局变量太多有诸多弊端，那么如何规避呢？

1、使用静态局部变量

在某些情况下，可以使用静态局部变量来替代全局变量，这样就避免了其他地方修改全局变量。

2、使用指针和引用

在函数内部，可以通过指针或引用来访问和修改外部变量的值，而无需直接声明为全局变量。

3、使用函数参数

在函数内部，尽量使用局部变量来存储临时数据，而不是依赖全局变量。

通过函数参数来传递需要的数据，并通过返回值来获取结果，而不是直接访问或修改全局变量。

4、封装和模块化

将相关的变量和函数封装在结构体或类中，通过接口进行访问和修改。

将代码划分为多个模块，每个模块负责特定的功能，并通过接口与其他模块交互。

5、定期优化代码

一个好的项目，肯定需要是定期维护和优化。比如优化数据结构和算法，减少不必要的全局变量，甚至定期重构部分模块代码。

6、增加审查团队

一般大公司会有专门的代码审查相关的部门，进行定期的代码审查，强调全局变量使用的危害，并鼓励团队成员寻找替代方案。

通过团队协作和讨论，共同寻找最佳实践，也能减少全局变量的使用。

------------ END ------------

●专栏《嵌入式工具》

●专栏《嵌入式开发》

●专栏《Keil教程》

●嵌入式专栏精选教程

点击“阅读原文”查看更多分享。