C语言开发单片机如何避免全局变量过多混乱

每个攻城狮的成长经历，目标总是相似的。

刚开始学习这门技术的时候，希望自己能独立做出各种各样智能的产品。

有了这能力，更有竞争力，也更挣钱，在越来越智能的时代不至于被抛弃。

可惜并不是每个人都能走到终点。

很多人学着学着就学不动了，最后遗憾放弃

有些人虽然走了很多弯路，凭借惊人毅力一样挺了过来。

这一路有太多的瓶颈需要突破，每一个都可能决定你是天选之人，还是淘汰者。

对于刚入行的工程师来说，有一个瓶颈非常难突破。

那就是如何让自己写出来的程序更专业。

有很长一段时间，虽然功能自己都能写出来，但是总是觉得自己的程序写的乱七八糟。

上图是我刚从事单片机开发1年写的程序，不知道大家看出什么问题没有。

我来给大家分析下：

1.整个项目程序都写在main函数里

2.全局变量过多

3.没模块化思维

就是这个项目程序逻辑，调到我快崩溃了。

其实产品也不复杂，就是一个太阳能热水器的控制板。

不过一组合起来，功能之间就会相互冲突得很厉害，导致改了这里，那里又出问题。

一出问题所有功能又要重新测一遍。

如果你没经历过这种问题，你不会理解程序架构的重要性。

程序架构的好坏会影响整个程序的方方面面。

比如说全局变量，后面我也意识到了这个问题。

就是全局变量多了，程序大了会掌控不住。

第一个是要避免全局变量名字重复，第二个如果哪个变量没做注释，1个月后干干净净。

特别是你把整个项目功能的全局变量定义在一起的时候，简直就是灾难。

但是，不用全局变量肯定也是不可能的。

只是要用的合理，这时候就比较考验工程师的经验了。

我是怎么做的？

拿我们无际单片机编程物联网网关那个课程项目来举例。

我采用了模块化编程的思维，从整体架构上分硬件层和应用层。

一般来说还有中间层，比如解析一些协议之类，项目中间层的代码不多，被我简化了。

每个功能模块的全局变量，都定义在各自的.c文件里。

跟我做的那个太阳能热水器控制板的程序对比，虽然全局变量的数量可能没变，但是很明显模块化的写法更加清晰。

当然，这不是让代码看起来更清爽这么简单，还有功能可扩展性强，可移植性强的优势。

可扩展性强，听起来是一个专业术语，可能很多新手不是很理解什么意思。

你试想一下，好不容易产品功能代码完成，测试也没问题了，交付给客户测试。

客户测试完，说要改功能，来来回回改个7,8次，你是不是撕碎他们的都有了？

这是常态，客户对于技术是一个小白，他并不知道他的一句话的背后，你需要付出多少。

有经验的工程师，从学会有能力偷懒开始，再急的项目，你做完还有空闲时间那才牛逼。

这就是代码可扩展性的重要性。

下面再来说说可移植性。

可移植性是相对单片机(硬件平台)来说的。

比如说这个项目以前我在STM32单片机上做的，现在芯片涨价了，老板要求换成GD32的替代。

这个时候就考验你程序的移植性了。

有经验工程师写出来的程序，一般只需要改改硬件层的外设接口，应用层的产品逻辑功能代码基本不用动。

而菜鸡可能就要重写整个代码了…

一个全局变量的问题，看似简单，要想解决，还是得站在整个程序架构的角度去思考。

如果，你离这个阶段还很远，还有一个比较便捷的方法。

就是用结构体。

用面向对象的思维，把同类的变量统一定义成结构体。

比如说时间分为年、月、日、周、时、分、秒。

如果用单独全局变量的形式，比较零散，也比较难管理。

这种，就比较适合用结构体了，因为这些都属于”时间”这个对象的参数。

类似的还有很多，比如说GPIO也算一个对象，参数有端口号、引脚号、输入模式、输出模式、频率等。

可以看看STM32固件库，就是很典型的面向对象编程思维。