/*********************************************************************************

Filename: 一线研发之声:嵌入式C编程经验 之 全局变量猛于虎

* Author:SedateFire          E-mail:SedateFire@126.com

* Version:1.001                 Time: 2012-01-05

* key: 嵌入式  os-less  全局变量  单片机

**********************************************************************************/

      工作也有些年头了,从一位技术新人成长到现在自诩小牛级别的人物,少不了要自己寻找资料阅读。论坛上、书店里、杂志上......要嘛是些菜鸟浅薄的自炫 处女贴,要嘛是高屋建瓴云里来雾里去的概念文,好不容易遇到个实践型高手写的文章,却在渐入佳境之际嘎然而止。本是隔靴搔痒,看完后心中更是郁结不已。也 罢,今日且强装回大牛,献丑谈一谈嵌入式C编程中全局变量问题。

         嵌入式特别是单片机os-less的程序,最易范的错误是全局变量满天飞。这个现象在早期汇编转型过来的程序员以及初学者中常见,这帮家伙几乎把全局变量当作函数形参来用。在.h文档里面定义许多杂乱的结构体,extern一堆令人头皮发麻的全局变量,然后再这个模块里边赋值123,那个模块里边判断123分支决定做什么。每当看到这种程序,我总要戚眉变脸而后拍桌怒喝。没错,就是怒喝。我不否认全局变量的重要性,但我认为要十分谨慎地使用它,滥用全局变量会引申带来其它更为严重的结构性系统问题。

 

诸位看官,且听我细细道来。

 

1. 它会造成不必要的常量频繁使用,特别当这个常量没有用宏定义“正名”时,代码阅读起来将万分吃力。

 

2. 它会导致软件分层的不合理,全局变量相当于一条快捷通道,它容易使程序员模糊了“设备层”和“应用层”之间的边界。写出来的底层程序容易自作多情地关注起上层的应用。这在软件系统的构建初期的确效率很高,功能调试进度一日千里,但到了后期往往bug一堆,处处“补丁”,雷区遍布。说是度日如年举步维艰也不为过。

 

3. 由于软件的分层不合理,到了后期维护,哪怕仅是增加修改删除小功能,往往要从上到下掘地三尺地修改,涉及大多数模块,而原有的代码注释却忘了更新修改,这个时候,交给后来维护者的系统会越来越像一个“泥潭”,注释的唯一作用只是使泥潭上方再加一些miyan瘴气。

 

4. 全局变量大量使用,少不了有些变量流连忘返于中断与主回圈程序之间。这个时候如果处理不当,系统的bug就是随机出现的,无规律的,这时候初步显示出病入膏肓的特征来了,没有大牛来力挽狂澜,注定慢性死亡。

 

        无需多言,您已经成功得到一个畸形的系统,它处于一个神秘的稳定状态!你看着这台机器,机器也看着你,相对无言,心中发毛。你不确定它什么时候会崩溃,也不晓得下一次投诉什么时候道理。

 

然后,我告诉大家现实层面的后果是什么。

 

1.“老人”气昂昂,因为系统离不开他,所有“雷区”只有他了然于心。当出现紧急的bug时,只有他能够搞定。你不但不能辞退他,还要给他加薪。

2. 新人见光死,但凡招聘来维护这个系统的,除了改出更多的bug外,基本上一个月内就走人,到了外面还宣扬这个公司的软件质量有够差够烂。

3.随着产品的后续升级,几个月没有接触这个系统的原创者会发现,很多雷区他本人也忘记了,于是每次的产品升级维护周期越来越长,因为修改一个功能会冒出很多bug,而按下一个bug,会弹出其他更多的bug。在这期间,又会产生更多的全局变量。终于有一天他告诉老板,不行啦不行啦,资源不够了,ram或者flash空间太小了,升级升级。

4. 客户投诉不断,售后也快崩溃了,业务员也不敢推荐此产品了,市场份额越来越小,公司形象越来越糟糕。

 

       要问我的对策吗,只有两个原则:

1. 能不用全局变量尽量不用,我想除了系统状态和控制参数、通信处理和一些需要效率的模块,其他的基本可以靠合理的软件分层和编程技巧来解决。

2. 如果不可避免需要用到,那能藏多深就藏多深。

1)如果只有某.c文件用,就static到该文件中,顺便把结构体定义也收进来;

2)如果只有一个函数用,那就static到函数里面去;

3)如果非要开放出去让人读取,那就用函数return出去,这样就是只读属性了;

4)如果非要遭人蹂躏赋值,好吧,我开放函数接口让你传参赋值;5)实在非要extern强奸我,我还可以严格控制包含我.h档的对象,而不是放到公共的includes.h中被人围观,丢人现眼。

         如此,你可明白我对全局变量的感悟有多深刻。悲催的我,已经把当年那些“老人”交给我维护的那些案子加班全部重新翻写了。你能明白吗,不要让人背后唾弃你哦。

 

2011-12-29 续篇

         承蒙小编抬爱,推荐了本博文,感激之余心中惶恐,特地详细看了下回复。这个主题最早是在论坛发表的,我发现那里的回复还是比较热烈的,也很高兴能够听到不同的声音。对于一些网友提到的,如果大量使用局部变量也会容易造成栈溢出的问题,还提到程序模型的概念。言之有理。所以特地来补充一下意见:

1.全局变量是不可避免要用到的,每一个设备底层几乎都需要它来记录当前状态,控制时序,起承转合。但是尽量不要用来传递参数,这个很忌讳的。

2.尽量把变量的作用范围控制在使用它的模块里面,如果其他模块要访问,就开个读或写函数接口出来,严格控制访问范围。这一点,C++的private属性就是这么干的。这对将来程序的调试也很有好处。C语言之所以有++版本,很大原因就是为了控制它的灵活性,要说面向对象的思想,C语言早已有之,亦可实现。

3.当一个模块里面的全局变量超过3个(含)时,就用结构体包起来吧。要归0便一起归0,省得丢三落四的。

4.在函数里面开个静态的全局变量全局组,是不占用栈空间的。只是有些编译器对于大块的全局数组,会放到和一般变量不同的地址区。若是在keil C51,因为是静态编译,栈爆掉了会报警,所以大可以尽情驰骋,注意交通规则就是了。

5.单片机的os-less系统中,只有栈没有堆的用法,那些默认对堆分配空间的“startup.s”,可以大胆的把堆空间干掉。

6.程序模型?如何分析抽象出来呢,从哪个角度进行模型构建呢?很愿意聆听网友的意见。本人一直以来都是从两个角度分析系统,事件--状态机迁移图 和 数据流图,前者分析控制流向,完善UI,后者可知晓系统数据的缘起缘灭。这些理论,院校的《软件工程》教材都有,大家不妨借鉴下。只不过那些理论,终究是起源于大型系统软件管理的,牛刀杀鸡,还是要裁剪一下的。

 

1、 消息机制弄好了可以避免全局变量 代价是效率
c++的class封装变量本质上还是全局变量
多个模块访问的话你得用class内的static
用c的话 折衷的办法是封在struct里面
然后用指针传struct变量的地址
这样没有全局变量 也不会有消息机制的效率问题
代价是模块耦合度
我比较喜欢这种办法

 

2、 在无操作系统的情况下,全局变量不是什么大问题,只要你的全局变量在中断函数里面没有被用到,那么就不会影响到你的全局变量的值,如果一个全局变量要在中断里面改变的话那就设置标志呗!!!

 

 

3、

一个子程序与外界的直接联系越少,则内聚性越好,而与外界联系,就是全局变量和参数 ,所以参数和全局变量越少越好,否则程序很难维护,可读性也不高。而且,全局变量占用固定地址不变,在函数中,或局部要读取它时还得到外界去找,而且在一 个大点的程序中如果大量使用全局变量会降低程序的可读性,而且占用了大量的有限空间,降低运行速度。

全局变量有些时候是无法避免的,只能尽量减少全局变量。我能想到的主要有三个方面:
1、通过函数参数传递数据或指针。对于回调函数,通常有一个参数是自定义的数据指针,可以利用这个参数传递类指针或者自定义一个结构的指针。
2、只在某一个函数中使用的变量可以定义为局部静态变量(在函数内部定义,前面加static修饰)。
3、把全局变量定义成一个结构,定义一个全局的结构体变量。

 

4、全局变量有其存在的必然法则,所谓全局变量不安全的论调也是杞人忧天,所有的不安全隐患来源于代码编写的不可靠,是人为因素和规范漏洞。有公司要求减 少全局变量这是对的,不许使用全局变量那是非常的不靠谱,系统编程中不止一处需要使用全局变量。在有些操作系统中可以使用系统规定的任务标志代替全局变 量,但是这只是全局变量的变形形式,并不是没有使用全局变量。而在某些没有操作系统的系统中就必须也只能使用全局变量了。使用全局变量最基本的一条就是能 使用静态全局变量不使用动态全局变量。
2、如果你真的想替代全局变量,其实是有办法的,就是使用单独的内存驱动。这种方法其实就是打肿脸充胖子,也许你觉得这样可靠,但其可靠性并不见得真的就高,而且非常占用资源。
其使用方式很简单,就是要实现4个函数
(1)申请标志
(2)读取标志
(3)更改标志
(4)删除标志
其中申请标志要保证只能使用一次
3、C++封装的概念在于面向对象,但是你要清楚一点C++只是C得扩充,是C的高级实现,所以所有在C++中能实现的功能都可以在C中实现,只不过实现比较复杂一些,如果感兴趣可以去看些C面向对象的书,其教你怎么用C实现面向对象