|
/********************************************************************************* * Filename: 一線(xiàn)研發(fā)之聲：嵌入式C編程經(jīng)驗 之 全局變量猛于虎 * Author：SedateFire E-mail:SedateFire@126.com * Version：1.001 Time: 2012-01-05 * key: 嵌入式 os-less 全局變量 單片機 **********************************************************************************/ 工作也有些年頭了，從一位技術(shù)新人成長(cháng)到現在自詡小牛級別的人物，少不了要自己尋找資料閱讀。論壇上、書(shū)店里、雜志上......要嘛是些菜鳥(niǎo)淺薄的自炫 處女貼，要嘛是高屋建瓴云里來(lái)霧里去的概念文，好不容易遇到個(gè)實(shí)踐型高手寫(xiě)的文章，卻在漸入佳境之際嘎然而止。本是隔靴搔癢，看完后心中更是郁結不已。也 罷，今日且強裝回大牛，獻丑談一談嵌入式C編程中全局變量問(wèn)題。 嵌入式特別是單片機os-less的程序，最易范的錯誤是全局變量滿(mǎn)天飛。這個(gè)現象在早期匯編轉型過(guò)來(lái)的程序員以及初學(xué)者中常見(jiàn)，這幫家伙幾乎把全局變量當作函數形參來(lái)用。在.h文檔里面定義許多雜亂的結構體，extern一堆令人頭皮發(fā)麻的全局變量，然后再這個(gè)模塊里邊賦值123，那個(gè)模塊里邊判斷123分支決定做什么。每當看到這種程序，我總要戚眉變臉而后拍桌怒喝。沒(méi)錯，就是怒喝。我不否認全局變量的重要性，但我認為要十分謹慎地使用它，濫用全局變量會(huì )引申帶來(lái)其它更為嚴重的結構性系統問(wèn)題。 諸位看官，且聽(tīng)我細細道來(lái)。 1. 它會(huì )造成不必要的常量頻繁使用，特別當這個(gè)常量沒(méi)有用宏定義“正名”時(shí)，代碼閱讀起來(lái)將萬(wàn)分吃力。 2. 它會(huì )導致軟件分層的不合理，全局變量相當于一條快捷通道，它容易使程序員模糊了“設備層”和“應用層”之間的邊界。寫(xiě)出來(lái)的底層程序容易自作多情地關(guān)注起上層的應用。這在軟件系統的構建初期的確效率很高，功能調試進(jìn)度一日千里，但到了后期往往bug一堆，處處“補丁”，雷區遍布。說(shuō)是度日如年舉步維艱也不為過(guò)。 3. 由于軟件的分層不合理，到了后期維護，哪怕僅是增加修改刪除小功能，往往要從上到下掘地三尺地修改，涉及大多數模塊，而原有的代碼注釋卻忘了更新修改，這個(gè)時(shí)候，交給后來(lái)維護者的系統會(huì )越來(lái)越像一個(gè)“泥潭”，注釋的唯一作用只是使泥潭上方再加一些迷煙瘴氣。 4. 全局變量大量使用，少不了有些變量流連忘返于中斷與主回圈程序之間。這個(gè)時(shí)候如果處理不當，系統的bug就是隨機出現的，無(wú)規律的，這時(shí)候初步顯示出病入膏肓的特征來(lái)了，沒(méi)有大牛來(lái)力挽狂瀾，注定慢性死亡。 無(wú)需多言，您已經(jīng)成功得到一個(gè)畸形的系統，它處于一個(gè)神秘的穩定狀態(tài)！你看著(zhù)這臺機器，機器也看著(zhù)你，相對無(wú)言，心中發(fā)毛。你不確定它什么時(shí)候會(huì )崩潰，也不曉得下一次投訴什么時(shí)候道理。 然后，我告訴大家現實(shí)層面的后果是什么。 1.“老人”氣昂昂，因為系統離不開(kāi)他，所有“雷區”只有他了然于心。當出現緊急的bug時(shí)，只有他能夠搞定。你不但不能辭退他，還要給他加薪。 2. 新人見(jiàn)光死，但凡招聘來(lái)維護這個(gè)系統的，除了改出更多的bug外，基本上一個(gè)月內就走人，到了外面還宣揚這個(gè)公司的軟件質(zhì)量有夠差夠爛。 3.隨著(zhù)產(chǎn)品的后續升級，幾個(gè)月沒(méi)有接觸這個(gè)系統的原創(chuàng )者會(huì )發(fā)現，很多雷區他本人也忘記了，于是每次的產(chǎn)品升級維護周期越來(lái)越長(cháng)，因為修改一個(gè)功能會(huì )冒出很多bug，而按下一個(gè)bug，會(huì )彈出其他更多的bug。在這期間，又會(huì )產(chǎn)生更多的全局變量。終于有一天他告訴老板，不行啦不行啦，資源不夠了，ram或者flash空間太小了，升級升級。 4. 客戶(hù)投訴不斷，售后也快崩潰了，業(yè)務(wù)員也不敢推薦此產(chǎn)品了，市場(chǎng)份額越來(lái)越小，公司形象越來(lái)越糟糕。 要問(wèn)我的對策嗎，只有兩個(gè)原則： 1. 能不用全局變量盡量不用，我想除了系統狀態(tài)和控制參數、通信處理和一些需要效率的模塊，其他的基本可以靠合理的軟件分層和編程技巧來(lái)解決。 2. 如果不可避免需要用到，那能藏多深就藏多深。 1)如果只有某.c文件用，就static到該文件中，順便把結構體定義也收進(jìn)來(lái)； 2)如果只有一個(gè)函數用，那就static到函數里面去； 3)如果非要開(kāi)放出去讓人讀取，那就用函數return出去，這樣就是只讀屬性了； 4)如果非要遭人蹂躪賦值，好吧，我開(kāi)放函數接口讓你傳參賦值；5)實(shí)在非要extern強奸我，我還可以嚴格控制包含我.h檔的對象，而不是放到公共的includes.h中被人圍觀(guān)，丟人現眼。 如此，你可明白我對全局變量的感悟有多深刻。悲催的我，已經(jīng)把當年那些“老人”交給我維護的那些案子加班全部重新翻寫(xiě)了。你能明白嗎，不要讓人背后唾棄你哦。 2011-12-29 續篇 承蒙小編抬愛(ài)，推薦了本博文，感激之余心中惶恐，特地詳細看了下回復。這個(gè)主題最早是在論壇發(fā)表的，我發(fā)現那里的回復還是比較熱烈的，也很高興能夠聽(tīng)到不同的聲音。對于一些網(wǎng)友提到的，如果大量使用局部變量也會(huì )容易造成棧溢出的問(wèn)題，還提到程序模型的概念。言之有理。所以特地來(lái)補充一下意見(jiàn)： 1.全局變量是不可避免要用到的，每一個(gè)設備底層幾乎都需要它來(lái)記錄當前狀態(tài)，控制時(shí)序，起承轉合。但是盡量不要用來(lái)傳遞參數，這個(gè)很忌諱的。 2.盡量把變量的作用范圍控制在使用它的模塊里面，如果其他模塊要訪(fǎng)問(wèn)，就開(kāi)個(gè)讀或寫(xiě)函數接口出來(lái)，嚴格控制訪(fǎng)問(wèn)范圍。這一點(diǎn)，C++的private屬性就是這么干的。這對將來(lái)程序的調試也很有好處。C語(yǔ)言之所以有++版本，很大原因就是為了控制它的靈活性，要說(shuō)面向對象的思想，C語(yǔ)言早已有之，亦可實(shí)現。 3.當一個(gè)模塊里面的全局變量超過(guò)3個(gè)(含)時(shí)，就用結構體包起來(lái)吧。要歸0便一起歸0，省得丟三落四的。 4.在函數里面開(kāi)個(gè)靜態(tài)的全局變量，全局數組，是不占用�？臻g的。只是有些編譯器對于大塊的全局數組，會(huì )放到和一般變量不同的地址區。若是在keil C51，因為是靜態(tài)編譯，棧爆掉了會(huì )報警，所以大可以盡情馳騁，注意交通規則就是了。 5.單片機的os-less系統中，只有棧沒(méi)有堆的用法，那些默認對堆分配空間的“startup.s”，可以大膽的把堆空間干掉。 6.程序模型？如何分析抽象出來(lái)呢，從哪個(gè)角度進(jìn)行模型構建呢？很愿意聆聽(tīng)網(wǎng)友的意見(jiàn)。本人一直以來(lái)都是從兩個(gè)角度分析系統，事件--狀態(tài)機遷移圖 和 數據流圖，前者分析控制流向，完善UI，后者可知曉系統數據的緣起緣滅。這些理論，院校的《軟件工程》教材都有，大家不妨借鑒下。只不過(guò)那些理論，終究是起源于大型系統軟件管理的，牛刀殺雞，還是要裁剪一下的。 |
| 大哥對這種一般單片機程序的設計思路果然是大徹大悟，我只是略有摸索，還沒(méi)有找到解決的方案，有個(gè)問(wèn)題我想問(wèn)下，就是有關(guān)對于全局變量的訪(fǎng)問(wèn)，我就是想不明白，那個(gè)直接改寫(xiě)其值和放于函數內部改寫(xiě)其值，不是一樣嗎？ |
| 說(shuō)的有道理 |
| 寫(xiě)的不錯 |
| 不錯. |
| 寫(xiě)得太好了 |
