C语言编程：全局变量别乱用，后果很严重

哈喽各位咱这儿有个叫麦鸽的今儿要去分享一篇文章这篇文章跟嵌入式编程有关联而且是专门讲其中全局变量这方面内容的。嵌入式进行开发尤其是针对单片机os-less的程序而言最容易出现的错误乃是全局变量到处都是。此现象于早期从汇编转型而来的程序员当中常见同时在初学者里也常见这伙人几乎将全局变量用作函数形参来使用。把许多杂乱的结构体定义在.h文档当中弄出一堆令人头痛的全局变量并声明为extern随后在这个模块里头给其赋值为123又在那个模块里头依据判断其为123的分支来决定要做些什么。每当瞅见这般程序我总会皱起眉头改变面容随后拍打桌子愤怒地大声呼喊。没错就是大声呼喊。不能否认全局变量有着其重要性然而我觉得对于它的使用应当抱着十分谨慎的态度要是滥用全局变量的话就会引发其他更为严重的、属于结构性的系统问题。为什么全局变量要越少越好会造成常量被不必要地频繁使用尤其是当此常量未用宏定义来“正名”时代码阅读起来会极其费劲十分吃力。它会致使软件分层出现不合理的状况全局变量宛如一条快捷通道它极易让程序员将“设备层”与“应用层”之间的边界给模糊掉所编写出来的底层程序易于自作多情地去关注那上层的应用。在软件系统构建的起始阶段这本确实效率蛮高功能调试的进展一日千里然而到了后期常常是毛病众多到处都需要“打补丁”布满了雷区。讲它度日如年、举步维艰也不算过分。是因为软件分层存在不合理之处以至于到了后期进行维护时哪怕仅仅是增添、修改或者删除一个小功能常常都得从最上面一直到底部进行全面且深入如同掘地三尺般的修改操作并且还会涉及到大多数的模块。原有代码注释却把更新修改给忘了这种时候那个叫给后来维护者的系统会变得越来越像一个所谓的“泥潭”注释有着的唯一作用不过就是让泥潭上方再多添一些带有迷惑性的烟雾瘴气罢了。全域变数大量运用着免不了会有一些变数在中断以及主回圈程序之间徘徊久久不愿离去。这种时候要是处理不妥当系统的漏洞就会随机冒出来毫无规律可循此时初步呈现出病入骨髓的特点没有顶尖高手来扭转局面必定会慢慢走向灭亡。不用多说什么您已然成功获取到一个呈现出怪异形态的系统它处于一种神秘的保持稳定的状态你望向那台机器那机器也朝向你彼此相对默默无语心里不禁泛起发毛之感。你无法确定它究竟会在何时出现崩溃状况也不清楚下一次投诉究竟会在什么时候到来。全局变量大量使用有什么后果神态昂扬的那位老者因系统对其有所依赖任何“雷区”独他心里清楚每当紧急的程序漏洞出现唯他能处理妥当你非但不可将其辞退还得为其增加薪资。才刚进来工作没几天的新人在被曝光后就快速终止工作只要是被特地招聘过来致力于维护这个系统的人员除了会修改出数量更多的程序漏洞之外基本上在一个月以内就会选择离职当他们到了公司外部之后还会大肆宣扬这个公司所推出在软件质量方面是多么的糟糕且劣质。随着产品在后续阶段进行升级原创者已有几个月未曾接触这个系统他会发现有很多雷区他自己也忘掉了所以每次产品升级维护的周期变得越来越长。由于修改一项功能会涌现出诸多漏洞然而处理一个漏洞时又会蹦出其他更多的漏洞在这个时段内还会生成更多的全局变量。总算到了那么一日他赶忙跑去跟老板讲不行了不行了呀资源已然不够用了ram的空间显著太小了不然就是flash的空间也小得可怜必须得升级必须得换代才能接着用呀。不断有客户进行投诉售后服务人员快要崩溃了业务员也不敢再推荐这款产品了市场份额正变得越来越小公司形象也愈发糟糕。要问对策只有两个原则若是能够不使用全局变量那就尽量别用我觉得呀除了系统状态以及控制参数还有通信处理以及一些对效率有要求的模块其他方面基本上是能够依靠合理的软件分层以及编程技巧去解决的。要是无可避开非得运用到那就藏得能多深就尽量往多深去藏。这样你可晓得我对全局变量所具有的感悟有多深切呀可怜悲哀的我将以往那些被称作“老人”的人交付给我进行维护的那些案件借助加班全部再次进行书写了。最后补充用到全局变量是难以避免的几乎每个设备底层都需要借助它去记录当下状态把控时序完成起承转合然而传递参数能不用全局变量就尽量别用这是很忌讳的。能控制变量作用范围的话尽量将其控制于使用该变量的模块之中要是其他模块需要进行访问那就去开设一个读或者写的函数接口以此严格把控访问范围。C的private属性就是针对这一点来做的这对于将来程序进行调试而言也是有着很大好处的。有版本存在于C语言之中很大原因其实就在于对其灵活性展开控制一事若谈及面向对象的思想C语言早就已经具备了并且也能够将之实现。要是一个模块里头全局变量数量达到三个或者超过三个那就拿结构体给包起来算了想要归零的话一块儿归零就行咯免得总是丢三落四的。当在函数里边开设一个静态的全局变量以及一个全局数组时其是不会占所用栈方面的空间的只是存在一些编译器对于那种大块的全局数组会将其放置到与一般变量不一样的地址区。要是处于keil C51的环境当中鉴于这属于静态编译一旦栈出现爆掉的情况就会发出警报因而完全能够畅快地尽情发挥只需留意交通规则便行了。在单片机的os - less系统里存在着这样一种情况那就是只有栈这种用法而不存在堆的用法对于那些默认会对堆进行分配空间操作的“startup.s”是能够大胆地将堆空间去除的。程序模型怎样去分析将其抽象得出呢从哪一个角度着手进行模型的构建呢十分乐意去聆听网友们的意见。我一直以来都从两个角度剖析系统一个角度是事件——状态机迁移图它用于分析控制流向进而完善UI另一个角度是数据流图借助它可以知晓系统数据的起始与终结情况。院校的《软件工程》教材里都有这些理论大家不妨去借鉴一下。只不过那些理论终究是从大型系统软件管理起源的用牛刀杀鸡还是要进行一下裁剪的。