程序的斷言密度(Assertion density)應(yīng)平均保持為每個(gè)函數(shù)最少兩個(gè)斷言。斷言可用于檢查現(xiàn)實(shí)運(yùn)行過(guò)程中本絕不應(yīng)出現(xiàn)的異常狀況,因此應(yīng)定義為Boolean測(cè)試。當(dāng)斷言失敗后,應(yīng)執(zhí)行明確的恢復(fù)操作。
如果靜態(tài)檢查工具證明斷言絕對(duì)不會(huì)Fail或Hold,則可認(rèn)為未遵守該原則。
原因:業(yè)界的代碼編寫(xiě)工作統(tǒng)計(jì)報(bào)告顯示,通過(guò)單元測(cè)試可發(fā)現(xiàn),通常我們所編寫(xiě)的每10-100行代碼中至少會(huì)存在一處缺陷。隨著斷言密度的增高,攔截缺陷的機(jī)會(huì)也會(huì)增大。
斷言的另一個(gè)重要之處在于,它是防御性編程(Defensive coding)策略的重要組成部分。我們可以使用斷言驗(yàn)證函數(shù)執(zhí)行前后的狀況,函數(shù)的執(zhí)行參數(shù)和返回值,以及循環(huán)不變式(Loop-invariant)。在完成性能關(guān)鍵代碼的測(cè)試工作后,可將斷言選擇性地禁用。
原則6 – 以最小范圍級(jí)別聲明數(shù)據(jù)對(duì)象(Declare Data Objects at Smallest Level of Scope)
該原則同時(shí)也是數(shù)據(jù)隱蔽(Data hiding)的基本原則。所有數(shù)據(jù)對(duì)象均必須以盡可能最小的范圍級(jí)別進(jìn)行聲明。
原因:如果某對(duì)象不在范圍內(nèi),意味著其值將無(wú)法引用或已損壞。該原則不鼓勵(lì)出于多種可能導(dǎo)致故障診斷工作變得更復(fù)雜的互斥意圖重用變量。
原則7 – 檢查參數(shù)和返回值(Check Parameters and Return Value)
應(yīng)在每次調(diào)用函數(shù)后檢查非空函數(shù)的返回值,并應(yīng)在每個(gè)函數(shù)內(nèi)部檢查參數(shù)的合法性。
在最嚴(yán)格的形式下,該原則意味著就算printf語(yǔ)句和文件close語(yǔ)句的返回值也應(yīng)進(jìn)行檢查。
原因:如果對(duì)一個(gè)錯(cuò)誤結(jié)果的響應(yīng)與對(duì)成功結(jié)果的響應(yīng)本不應(yīng)有任何區(qū)別,那么很明顯需要檢查返回值。通常對(duì)close和printf的調(diào)用便符合這種情況。此時(shí)一種可行的方法是將函數(shù)的返回值明確拋出給void,這意味著開(kāi)發(fā)者明確(而非意外地)決定忽略該返回值。
原則8 – 限制預(yù)處理程序的使用(Limited Use of Preprocessor)
預(yù)處理程序(Preprocessor)應(yīng)僅限用于頭文件和宏定義。遞歸的宏調(diào)用、令牌傳遞,以及變量參數(shù)列表均不允許使用。就算大型應(yīng)用程序開(kāi)發(fā)工作中,標(biāo)準(zhǔn)樣板文件(Boilerplate)之外也可能有必要使用一兩個(gè)以上的條件編譯指令,這是為了避免將同一個(gè)頭文件包含多次。每個(gè)這種用法必須通過(guò)工具檢查器添加標(biāo)記,并通過(guò)代碼闡述原因。
原因:C語(yǔ)言預(yù)處理程序是一個(gè)強(qiáng)大但較為含糊的工具,有可能徹底破壞代碼的清晰度,并讓很多基于文本的檢查器產(chǎn)生混淆。就算具備正式的語(yǔ)言定義,包含無(wú)界限預(yù)處理程序代碼的構(gòu)造也會(huì)顯得非常難以解讀。
有關(guān)條件編譯的注意事項(xiàng)同樣很重要 – 就算只使用10個(gè)條件編譯指令,代碼也有會(huì)產(chǎn)生1024(2^10)個(gè)可能的版本,這會(huì)導(dǎo)致測(cè)試工作量劇增。
原則9 – 限制指針的使用(Limited Use of Pointers)
指針的使用必須加以限制。通常只允許不超過(guò)一層的解引用(Dereferencing)。指針解引用操作不應(yīng)隱藏在typedef聲明或宏定義內(nèi)部。此外函數(shù)指針也是不允許使用的。
原因:指針很容易被濫用,就算專(zhuān)家也難以徹底避免。指針的存在會(huì)使得我們難以跟蹤或分析程序中數(shù)據(jù)的流動(dòng),尤其是在使用基于工具的靜態(tài)分析器執(zhí)行這些操作時(shí)。函數(shù)指針還會(huì)對(duì)靜態(tài)分析器所能執(zhí)行的檢查類(lèi)型產(chǎn)生限制,因此除非有非常必要的理由,否則一般不推薦使用。如果使用函數(shù)指針,通常幾乎將無(wú)法通過(guò)工具證明遞歸的缺席,此時(shí)只能提供其他方法彌補(bǔ)這種分析能力的缺失。
原則10 – 編譯所有代碼(Compile all Code)
從開(kāi)發(fā)工作第一天開(kāi)始時(shí),就必須對(duì)所有代碼進(jìn)行編譯。必須啟用編譯器的警告功能,并使用最細(xì)致的檢查選項(xiàng)。代碼必須能通過(guò)這樣的設(shè)置在不產(chǎn)生任何警報(bào)的情況下順利編譯完成。
所有代碼必須每天一次、使用至少一種(多種則更好)最新型的靜態(tài)源代碼分析器進(jìn)行檢查,并且必須順利通過(guò)分析器的整個(gè)檢查過(guò)程而不產(chǎn)生任何警告。
原因:市面上有很多效果卓越的源代碼分析器,其中很多甚至是以免費(fèi)軟件的形式發(fā)布的。對(duì)于這樣可以直接使用的現(xiàn)成技術(shù),任何軟件開(kāi)發(fā)工作都沒(méi)理由不加以充分利用。
如果編譯器或靜態(tài)分析器遇到問(wèn)題,導(dǎo)致問(wèn)題/錯(cuò)誤的代碼必須重寫(xiě),這樣才能進(jìn)一步改善代碼質(zhì)量。
NASA對(duì)這些原則的看法為:“這些原則就如同汽車(chē)安全帶,也許一開(kāi)始會(huì)覺(jué)得有些不舒適,但很快會(huì)變成每個(gè)人的第二本能,到時(shí)候很難想象會(huì)有人不這么做?!?/p>
此文在Reddit引發(fā)了熱烈的討論,現(xiàn)將部分有價(jià)值內(nèi)容摘錄如下:
本文的很多原則提到使用靜態(tài)代碼分析器進(jìn)行分析是一種更簡(jiǎn)單可靠的辦法。如果我在開(kāi)發(fā)C或C++代碼,有什么好用的免費(fèi)靜態(tài)代碼分析器嗎?一方面我想看看這些分析器的工作效果,另一方面,我一直在使用另一個(gè)極為糟糕的分析器,想對(duì)比一下來(lái)了解原本使用的分析器到底有多糟糕。
我覺(jué)得有必要提醒大家,本文所說(shuō)的“安全關(guān)鍵程序”是一種面向特定領(lǐng)域的術(shù)語(yǔ)。每次網(wǎng)上流傳類(lèi)似這樣的東西時(shí),大家都會(huì)試圖將相關(guān)內(nèi)容應(yīng)用在一般常規(guī)用途的軟件中,但實(shí)際上除非你的軟件中出現(xiàn)的無(wú)法處理的異常真的會(huì)致命,否則并不需要如此嚴(yán)格(也許也不應(yīng)該這樣做,因?yàn)榇蟛糠执祟?lèi)原則會(huì)在代碼可讀性和可維護(hù)性方面造成不小的麻煩)。
原則3 – 不使用動(dòng)態(tài)內(nèi)存分配
這條讓我大吃一驚。我很好奇,如果不使用動(dòng)態(tài)內(nèi)存分配,你到底如何編寫(xiě)哪怕很小規(guī)模的程序!是否就只在程序運(yùn)行時(shí)分配一大塊內(nèi)存,隨后程序的所有執(zhí)行都在這塊內(nèi)存中進(jìn)行?
我倒是對(duì)于NASA使用C語(yǔ)言感覺(jué)驚訝,我本想著他們會(huì)使用Ada之類(lèi)的東西。
這些原則中很多原則與我在ASEA(現(xiàn)ABB)擔(dān)任開(kāi)發(fā)者時(shí)所遵守的原則是相同的,拋開(kāi)這些不談,同時(shí)拋開(kāi)有關(guān)預(yù)處理程序的原則不談,我們當(dāng)時(shí)主要使用Pascal,對(duì)于遞歸函數(shù)也制訂了相應(yīng)的原則。我編寫(xiě)了一個(gè)預(yù)處理程序,這樣就可以保證開(kāi)發(fā)者能夠獲得恰當(dāng)?shù)穆暶鳎鵁o(wú)需擔(dān)心這些問(wèn)題,此外我們還會(huì)按照標(biāo)準(zhǔn)設(shè)置程序代碼的縮進(jìn)和格式,畢竟每個(gè)程序員在代碼格式方面都有一些個(gè)人偏好。所有程序都有必要在這些問(wèn)題方面由其他程序員進(jìn)行交叉檢查。
他們?yōu)槭裁床话堰@些原則強(qiáng)制應(yīng)用到編譯器中?可以通過(guò) -WNasa 或其他類(lèi)似的東西告訴開(kāi)發(fā)者是否違反了這些原則。此外還需要使用 std lib C 來(lái)維護(hù)這些嚴(yán)格的原則。
建議挺好,就是不明白為什么不用自動(dòng)化的方法來(lái)應(yīng)用(或者他們正是這樣做的?)
電子發(fā)燒友App


















評(píng)論