嵌入式C語言中的全局變量問題

歡迎加入技術交流QQ群（2000人）：電力電子技術與新能源?920776074

電力電子技術與新能源論壇

www.21micro-grid.com

小編推薦值得一看的書單電力電子技術與新能源小店

大家好，今天分享一篇關于嵌入式C編程中全局變量問題的文章。希望對大家有所啟發。

嵌入式特別是單片機os-less的程序，最易范的錯誤是全局變量滿天飛。

這個現象在早期匯編轉型過來的程序員以及初學者中常見，這幫家伙幾乎把全局變量當作函數形參來用。

在.h文檔里面定義許多雜亂的結構體，extern一堆令人頭皮發麻的全局變量，然后再這個模塊里邊賦值123，那個模塊里邊判斷123分支決定做什么。

每當看到這種程序，我總要戚眉變臉而后拍桌怒喝。

沒錯，就是怒喝。我不否認全局變量的重要性，但我認為要十分謹慎地使用它，濫用全局變量會引申帶來其它更為嚴重的結構性系統問題。

諸位看官，且聽我細細道來

1、它會造成不必要的常量頻繁使用，特別當這個常量沒有用宏定義“正名”時，代碼閱讀起來將萬分吃力。

2、它會導致軟件分層的不合理，全局變量相當于一條快捷通道，它容易使程序員模糊了“設備層”和“應用層”之間的邊界。寫出來的底層程序容易自作多情地關注起上層的應用。這在軟件系統的構建初期的確效率很高，功能調試進度一日千里，但到了后期往往bug一堆，處處“補丁”，雷區遍布。說是度日如年舉步維艱也不為過。

3、由于軟件的分層不合理，到了后期維護，哪怕僅是增加修改刪除小功能，往往要從上到下掘地三尺地修改，涉及大多數模塊，而原有的代碼注釋卻忘了更新修改，這個時候，交給后來維護者的系統會越來越像一個“泥潭”，注釋的唯一作用只是使泥潭上方再加一些迷煙瘴氣。

4、全局變量大量使用，少不了有些變量流連忘返于中斷與主回圈程序之間。這個時候如果處理不當，系統的bug就是隨機出現的，無規律的，這時候初步顯示出病入膏肓的特征來了，沒有大牛來力挽狂瀾，注定慢性死亡。

無需多言，您已經成功得到一個畸形的系統，它處于一個神秘的穩定狀態！你看著這臺機器，機器也看著你，相對無言，心中發毛。你不確定它什么時候會崩潰，也不曉得下一次投訴什么時候道理。

現實層面的后果是什么

1、“老人”氣昂昂，因為系統離不開他，所有“雷區”只有他了然于心。當出現緊急的bug時，只有他能夠搞定。你不但不能辭退他，還要給他加薪。

2、新人見光死，但凡招聘來維護這個系統的，除了改出更多的bug外，基本上一個月內就走人，到了外面還宣揚這個公司的軟件質量有夠差夠爛。

3、隨著產品的后續升級，幾個月沒有接觸這個系統的原創者會發現，很多雷區他本人也忘記了，于是每次的產品升級維護周期越來越長，因為修改一個功能會冒出很多bug，而按下一個bug，會彈出其他更多的bug。在這期間，又會產生更多的全局變量。終于有一天他告訴老板，不行啦不行啦，資源不夠了，ram或者flash空間太小了，升級升級。

4、客戶投訴不斷，售后也快崩潰了，業務員也不敢推薦此產品了，市場份額越來越小，公司形象越來越糟糕。

要說對策，只有兩個原則

1、能不用全局變量盡量不用，我想除了系統狀態和控制參數、通信處理和一些需要效率的模塊，其他的基本可以靠合理的軟件分層和編程技巧來解決。

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

a. 如果只有某.c文件用，就static到該文件中，順便把結構體定義也收進來；

b. 如果只有一個函數用，那就static到函數里面去；

c. 如果非要開放出去讓人讀取，那就用函數return出去，這樣就是只讀屬性了；

d. 如果非要遭人蹂躪賦值，好吧，我開放函數接口讓你傳參賦值；

實在非要extern，我還可以嚴格控制包含我.h檔的對象，而不是放到公共的includes.h中被人圍觀，丟人現眼。

如此，你可明白我對全局變量的感悟有多深刻。悲催的我，已經把當年那些“老人”交給我維護的那些案子加班全部重新翻寫了。你能明白嗎，不要讓人背后唾棄你哦。

最后補充一下意見

1、全局變量是不可避免要用到的，每一個設備底層幾乎都需要它來記錄當前狀態，控制時序，起承轉合。但是盡量不要用來傳遞參數，這個很忌諱的。

2、盡量把變量的作用范圍控制在使用它的模塊里面，如果其他模塊要訪問，就開個讀或寫函數接口出來，嚴格控制訪問范圍。這一點，C++的private屬性就是這么干的。這對將來程序的調試也很有好處。C語言之所以有++版本，很大原因就是為了控制它的靈活性，要說面向對象的思想，C語言早已有之，亦可實現。

3、當一個模塊里面的全局變量超過3個(含)時，就用結構體包起來吧。要歸0便一起歸0，省得丟三落四的。

4、在函數里面開個靜態的全局變量，全局數組，是不占用?？臻g的。只是有些編譯器對于大塊的全局數組，會放到和一般變量不同的地址區。若是在keil C51，因為是靜態編譯，棧爆掉了會報警，所以大可以盡情馳騁，注意交通規則就是了。

5、單片機的os-less系統中，只有棧沒有堆的用法，那些默認對堆分配空間的“startup.s”，可以大膽的把堆空間干掉。

6、程序模型？如何分析抽象出來呢，從哪個角度進行模型構建呢？很愿意聆聽網友的意見。本人一直以來都是從兩個角度分析系統，事件--狀態機遷移圖 和 數據流圖，前者分析控制流向，完善UI，后者可知曉系統數據的緣起緣滅。這些理論，院校的《軟件工程》教材都有，大家不妨借鑒下。只不過那些理論，終究是起源于大型系統軟件管理的，牛刀殺雞，還是要裁剪一下的。

文章首尾冠名廣告正式招商，功率器件：IGBT，MOS，SiC，GaN，磁性器件，電源芯片，DSP，MCU，新能源廠家都可合作，有意者加微信號1768359031詳談。

說明：本文來源網絡；文中觀點僅供分享交流，不代表本公眾號立場，轉載請注明出處，如涉及版權等問題，請您告知，我們將及時處理。

電力電子技術與新能源通訊錄：

Please?clik the advertisement and exit

重點

如何下載《電力電子技術與新能源》板塊內高清PDF電子書

點擊文章底部閱讀原文，訪問電力電子技術與新能源論壇（www.21micro-grid.com）下載！

或者轉發所要文章到朋友圈不分組不屏蔽，然后截圖發給小編（微信：1413043922），小編審核后將文章發你！

看完有收獲？請分享給更多人

公告：

? ??在這里有電力電子技術：光伏并網逆變器（PV建模，MPPT，并網控制，LCL濾波，孤島效應），光伏離網，光伏儲能，風電變流器（雙饋、直驅），雙向變流器PCS，新能源汽車，充電樁，車載電源，數字電源，雙向DCDC（LLC，移相全橋，DAB），儲能（鋰電池、超級電容），低電壓穿越（LVRT），高電壓穿越，虛擬同步發電機，多智能體，電解水，燃料電池，能量管理系統（直流微網、交流微網）以及APF，SVG ，DVR，UPQC等諧波治理和無功補償裝置等。

更多精彩點下方“閱讀原文”！