【經(jīng)驗(yàn)分享】為追求100%可靠，NASA提出10條代碼編寫原則

2017-05-18 by:CAE仿真在線來源:互聯(lián)網(wǎng)

美國宇航局(National Aeronautics and Space Administration,縮寫為 NASA)是美國聯(lián)邦政府的一個(gè)獨(dú)立機(jī)構(gòu),負(fù)責(zé)制定、實(shí)施美國的民用太空計(jì)劃、與開展航空科學(xué)暨太空科學(xué)的研究。在太空計(jì)劃之外,美國國家航空航天局還進(jìn)行長期的民用以及軍用航空航天研究。

在普通人的眼中,NASA是一個(gè)很“高級”的機(jī)構(gòu),其成員包含大量不同領(lǐng)域的科學(xué)家和研究人員。與其他任何組織機(jī)構(gòu)類似,NASA的日常工作,以及所執(zhí)行的幾乎全部項(xiàng)目也離不開計(jì)算機(jī)的輔助,出于需求的特殊性和重要性,他們所使用的很多計(jì)算機(jī)軟件都是內(nèi)部自行開發(fā)的,在一些重要項(xiàng)目的關(guān)鍵領(lǐng)域發(fā)揮著作用。

去年,一位前NASA實(shí)習(xí)生把美國阿波羅登月項(xiàng)目的11號計(jì)算機(jī) --- 阿波羅導(dǎo)航計(jì)算機(jī) (Apollo Guidance Computer) 系統(tǒng)源代碼上傳到了 GitHub,此舉在開發(fā)者群體中引起了極大的熱議。

此外,NASA官方也已將自己的部分源代碼開源到GitHub,讓我們得以管窺這一頂尖科研機(jī)構(gòu)內(nèi)的聰明大腦們寫代碼的專業(yè)水平。

大型的復(fù)雜軟件項(xiàng)目通常會遵循一定的代碼編寫標(biāo)準(zhǔn)和指南。這些指南奠定了軟件開發(fā)過程中必須遵守的基本原則:

代碼的結(jié)構(gòu)如何安排?
應(yīng)不應(yīng)當(dāng)使用哪些語言特性?

出于效果的角度考慮,這些原則必須盡可能精簡并且必須足夠具體,這樣才能更好地被人理解并記憶。

本文將介紹由NASA噴氣推進(jìn)實(shí)驗(yàn)室首席科學(xué)家Gerard J. Holzmann所提出的,側(cè)重于安全參數(shù)的10條代碼編寫原則。當(dāng)然,這些原則也適用于其他編程語言。

為NASA工作的全球頂尖程序員在編寫高度安全的代碼時(shí)就沿襲了這樣的一套指南。實(shí)際上,很多組織,包括NASA噴氣推進(jìn)實(shí)驗(yàn)室主要會選擇使用C語言編寫代碼。

原因在于這種語言具備完善的工具支持,包括邏輯模型分離器、調(diào)試器、靜態(tài)編譯器、源代碼分析器,以及度量工具等。

有時(shí)候,編寫代碼必須遵守一定的原則,尤其是在代碼的正確性會對人的生命產(chǎn)生決定性影響的領(lǐng)域,例如飛機(jī)、將宇航員送上同步軌道的航天器,以及距離居住地僅幾英里遠(yuǎn)的核電站等設(shè)施運(yùn)行的控制代碼。

原則1 – 簡化控制流程

使用盡可能精簡的控制流程構(gòu)造編寫程序 – 不要使用setjmp或longjmp構(gòu)造、goto語句,以及直接或間接的recursion。

原因:簡化控制流程有助于提高代碼清晰度,增強(qiáng)代碼可驗(yàn)證能力。不使用遞歸,便不會產(chǎn)生循環(huán)的函數(shù)調(diào)用圖,這樣也可證明所有本應(yīng)有界的執(zhí)行實(shí)際上都是有界的。

原則2 – 為循環(huán)設(shè)置上限次數(shù)

所有循環(huán)必須有固定次數(shù)的上限。我們可以通過驗(yàn)證工具靜態(tài)地證明,為循環(huán)中迭代數(shù)量所設(shè)立的上限次數(shù)未被超越。

如果無法以靜態(tài)方式對循環(huán)的次數(shù)界限加以證明,則可認(rèn)為未遵守該原則。

原因:為循環(huán)設(shè)置次數(shù)界限,避免使用遞歸,這些做法有助于預(yù)防代碼失控。然而該原則無法適用于本就不應(yīng)終止的迭代(例如進(jìn)程調(diào)度器)。此時(shí)將沿用該原則的逆向原則:必須能夠靜態(tài)地證明迭代不能終止。

原則3 – 不使用動態(tài)內(nèi)存分配

不要在初始化完成后進(jìn)行動態(tài)內(nèi)存分配。

原因:諸如malloc等內(nèi)存分配機(jī)制,以及垃圾回收器通常會產(chǎn)生無法預(yù)知的行為,進(jìn)而可能會對性能產(chǎn)生影響。更重要的是,還有可能因?yàn)槌绦騿T的失誤造成內(nèi)存錯(cuò)誤,例如:

試圖分配超過可用物理內(nèi)存數(shù)的內(nèi)存
忘記釋放內(nèi)存
繼續(xù)使用已被釋放的內(nèi)存
對已分配內(nèi)存進(jìn)行越界使用

應(yīng)強(qiáng)制所有模塊位于固定大小、預(yù)先分配的存儲區(qū)域中,借此可避免此類問題,并簡化內(nèi)存使用情況的驗(yàn)證工作。

堆中未分配內(nèi)存的情況下,動態(tài)請求內(nèi)存的唯一方式是使用棧內(nèi)存。

原則4 – 不使用冗長的函數(shù)

任何函數(shù)的長度不應(yīng)超過使用標(biāo)準(zhǔn)參考格式(每個(gè)聲明最多一行,每個(gè)語句最多一行)打印的紙張上一頁紙所能容納的字符數(shù)。這意味著函數(shù)的代碼不應(yīng)超過60行。

原因:過長的函數(shù)通常意味著結(jié)構(gòu)并非最優(yōu)。每個(gè)函數(shù)都應(yīng)是可理解且可驗(yàn)證的單一邏輯單位。如果在計(jì)算機(jī)顯示器上需要多屏界面才能完整顯示,這樣的邏輯單位通常會極難理解。

原則5 – 低斷言密度

【經(jīng)驗(yàn)分享】為追求100%可靠，NASA提出10條代碼編寫原則fluent分析案例圖片2

程序的斷言密度(Assertion density)應(yīng)平均保持為每個(gè)函數(shù)最少兩個(gè)斷言。斷言可用于檢查現(xiàn)實(shí)運(yùn)行過程中本絕不應(yīng)出現(xiàn)的異常狀況,因此應(yīng)定義為Boolean測試。當(dāng)斷言失敗后,應(yīng)執(zhí)行明確的恢復(fù)操作。

如果靜態(tài)檢查工具證明斷言絕對不會Fail或Hold,則可認(rèn)為未遵守該原則。

原因:業(yè)界的代碼編寫工作統(tǒng)計(jì)報(bào)告顯示,通過單元測試可發(fā)現(xiàn),通常我們所編寫的每10-100行代碼中至少會存在一處缺陷。隨著斷言密度的增高,攔截缺陷的機(jī)會也會增大。

斷言的另一個(gè)重要之處在于,它是防御性編程(Defensive coding)策略的重要組成部分。我們可以使用斷言驗(yàn)證函數(shù)執(zhí)行前后的狀況,函數(shù)的執(zhí)行參數(shù)和返回值,以及循環(huán)不變式(Loop-invariant)。在完成性能關(guān)鍵代碼的測試工作后,可將斷言選擇性地禁用。

原則6 – 以最小范圍級別聲明數(shù)據(jù)對象

該原則同時(shí)也是數(shù)據(jù)隱蔽(Data hiding)的基本原則。所有數(shù)據(jù)對象均必須以盡可能最小的范圍級別進(jìn)行聲明。

原因:如果某對象不在范圍內(nèi),意味著其值將無法引用或已損壞。該原則不鼓勵(lì)出于多種可能導(dǎo)致故障診斷工作變得更復(fù)雜的互斥意圖重用變量。

原則7 – 檢查參數(shù)和返回值

應(yīng)在每次調(diào)用函數(shù)后檢查非空函數(shù)的返回值,并應(yīng)在每個(gè)函數(shù)內(nèi)部檢查參數(shù)的合法性。

在最嚴(yán)格的形式下,該原則意味著就算printf語句和文件close語句的返回值也應(yīng)進(jìn)行檢查。

原因:如果對一個(gè)錯(cuò)誤結(jié)果的響應(yīng)與對成功結(jié)果的響應(yīng)本不應(yīng)有任何區(qū)別,那么很明顯需要檢查返回值。通常對close和printf的調(diào)用便符合這種情況。此時(shí)一種可行的方法是將函數(shù)的返回值明確拋出給void,這意味著開發(fā)者明確(而非意外地)決定忽略該返回值。

原則8 – 限制預(yù)處理程序的使用

預(yù)處理程序(Preprocessor)應(yīng)僅限用于頭文件和宏定義。遞歸的宏調(diào)用、令牌傳遞,以及變量參數(shù)列表均不允許使用。就算大型應(yīng)用程序開發(fā)工作中,標(biāo)準(zhǔn)樣板文件(Boilerplate)之外也可能有必要使用一兩個(gè)以上的條件編譯指令,這是為了避免將同一個(gè)頭文件包含多次。每個(gè)這種用法必須通過工具檢查器添加標(biāo)記,并通過代碼闡述原因。

原因:C語言預(yù)處理程序是一個(gè)強(qiáng)大但較為含糊的工具,有可能徹底破壞代碼的清晰度,并讓很多基于文本的檢查器產(chǎn)生混淆。就算具備正式的語言定義,包含無界限預(yù)處理程序代碼的構(gòu)造也會顯得非常難以解讀。

有關(guān)條件編譯的注意事項(xiàng)同樣很重要 – 就算只使用10個(gè)條件編譯指令,代碼也有會產(chǎn)生1024(2^10)個(gè)可能的版本,這會導(dǎo)致測試工作量劇增。

原則9 – 限制指針的使用

指針的使用必須加以限制。通常只允許不超過一層的解引用(Dereferencing)。指針解引用操作不應(yīng)隱藏在typedef聲明或宏定義內(nèi)部。此外函數(shù)指針也是不允許使用的。

原因:指針很容易被濫用,就算專家也難以徹底避免。指針的存在會使得我們難以跟蹤或分析程序中數(shù)據(jù)的流動,尤其是在使用基于工具的靜態(tài)分析器執(zhí)行這些操作時(shí)。函數(shù)指針還會對靜態(tài)分析器所能執(zhí)行的檢查類型產(chǎn)生限制,因此除非有非常必要的理由,否則一般不推薦使用。如果使用函數(shù)指針,通常幾乎將無法通過工具證明遞歸的缺席,此時(shí)只能提供其他方法彌補(bǔ)這種分析能力的缺失。

原則10 – 編譯所有代碼

從開發(fā)工作第一天開始時(shí),就必須對所有代碼進(jìn)行編譯。必須啟用編譯器的警告功能,并使用最細(xì)致的檢查選項(xiàng)。代碼必須能通過這樣的設(shè)置在不產(chǎn)生任何警報(bào)的情況下順利編譯完成。

所有代碼必須每天一次,使用至少一種(多種則更好)最新型的靜態(tài)源代碼分析器進(jìn)行檢查,并且必須順利通過分析器的整個(gè)檢查過程而不產(chǎn)生任何警告。

原因:市面上有很多效果卓越的源代碼分析器,其中很多甚至是以免費(fèi)軟件的形式發(fā)布的。對于這樣可以直接使用的現(xiàn)成技術(shù),任何軟件開發(fā)工作都沒理由不加以充分利用。

如果編譯器或靜態(tài)分析器遇到問題,導(dǎo)致問題/錯(cuò)誤的代碼必須重寫,這樣才能進(jìn)一步改善代碼質(zhì)量。

NASA對這些原則的看法為:“這些原則就如同汽車安全帶,也許一開始會覺得有些不舒適,但很快會變成每個(gè)人的第二本能,到時(shí)候很難想象會有人不這么做。”

此文在Reddit引發(fā)了熱烈的討論,現(xiàn)將部分有價(jià)值內(nèi)容摘錄如下:

@fluffynukeit:本文的很多原則提到使用靜態(tài)代碼分析器進(jìn)行分析是一種更簡單可靠的辦法。如果我在開發(fā)C或C++代碼,有什么好用的免費(fèi)靜態(tài)代碼分析器嗎?一方面我想看看這些分析器的工作效果,另一方面,我一直在使用另一個(gè)極為糟糕的分析器,想對比一下來了解原本使用的分析器到底有多糟糕。

@tobascodagama:我覺得有必要提醒大家,本文所說的“安全關(guān)鍵程序”是一種面向特定領(lǐng)域的術(shù)語。每次網(wǎng)上流傳類似這樣的東西時(shí),大家都會試圖將相關(guān)內(nèi)容應(yīng)用在一般常規(guī)用途的軟件中,但實(shí)際上除非你的軟件中出現(xiàn)的無法處理的異常真的會致命,否則并不需要如此嚴(yán)格(也許也不應(yīng)該這樣做,因?yàn)榇蟛糠执祟愒瓌t會在代碼可讀性和可維護(hù)性方面造成不小的麻煩)。

@xianbaun:原則3 – 不使用動態(tài)內(nèi)存分配,這條讓我大吃一驚。我很好奇,如果不使用動態(tài)內(nèi)存分配,你到底如何編寫哪怕很小規(guī)模的程序!是否就只在程序運(yùn)行時(shí)分配一大塊內(nèi)存,隨后程序的所有執(zhí)行都在這塊內(nèi)存中進(jìn)行?

@aim2free:我倒是對于NASA使用C語言感覺驚訝,我本想著他們會使用Ada之類的東西。這些原則中很多原則與我在ASEA(現(xiàn)ABB)擔(dān)任開發(fā)者時(shí)所遵守的原則是相同的,拋開這些不談,同時(shí)拋開有關(guān)預(yù)處理程序的原則不談,我們當(dāng)時(shí)主要使用Pascal,對于遞歸函數(shù)也制訂了相應(yīng)的原則。我編寫了一個(gè)預(yù)處理程序,這樣就可以保證開發(fā)者能夠獲得恰當(dāng)?shù)穆暶?而無需擔(dān)心這些問題,此外我們還會按照標(biāo)準(zhǔn)設(shè)置程序代碼的縮進(jìn)和格式,畢竟每個(gè)程序員在代碼格式方面都有一些個(gè)人偏好。所有程序都有必要在這些問題方面由其他程序員進(jìn)行交叉檢查。

@NewYorkCityGent:他們?yōu)槭裁床话堰@些原則強(qiáng)制應(yīng)用到編譯器中?可以通過 -WNasa 或其他類似的東西告訴開發(fā)者是否違反了這些原則。此外還需要使用 std lib C 來維護(hù)這些嚴(yán)格的原則。建議挺好,就是不明白為什么不用自動化的方法來應(yīng)用(或者他們正是這樣做的?)

你有什么想法或者想說的,歡迎評論區(qū)留言討論。另外,本文為翻譯文章,有表述不妥之處,還請指正。原文鏈接:

http://www.rankred.com/nasa-coding-rules/

作者|RankRed 編輯|大愚若智
-------------------免責(zé)申明---------------------

本著學(xué)習(xí)交流的目的,自公眾號聊聊架構(gòu)轉(zhuǎn)載該文,如有不適,請聯(lián)系kf#1cae.com(請用@代替#)進(jìn)行處理,謝謝理解與支持

開放分享：優(yōu)質(zhì)有限元技術(shù)文章,助你自學(xué)成才