美國航空航天局（NASA，以下皆用英文簡稱）有一套自己的編碼標準，以確保所有NASA應用的代碼質量和安全。這些標準漸漸演變適用于廣大的軟件開發行業。

代碼安全規則

JPL（噴氣推進實驗室）的***科學家Gerard J. Holzmann表示，甚至是關鍵應用的代碼質量也因為大量任意的規則和不一致的準則而受害。這也是為什么實驗室要發布編碼十誡來管轄所有NASA軟件的原因。

[[141315]]

Holzmann和團隊在設計這些軟件開發規則時，時刻謹記代碼的安全問題。該規則明確寫明是關于C語言的——C語言是NASA用于備份關鍵安全代碼的支柱語言，有著悠久的歷史和廣泛的工具支持。不過，這些也可應用于其他大多數編程語言：

• 限制所有代碼為簡單的控制流結構——不使用goto語句，不使用setjmp和longjmp結構以及直接或間接的遞歸。

• 所有的循環必須有固定的上限。用檢查工具靜態地證明，預先設定的上限是一個循環不能超過的迭代次數，在數學上是可能的。如果循環限制不能靜態證明，那么就違背了此條規則。

• 初始化后不要使用動態內存分配。

• 一個函數在標準參考格式下——每個語句一行，每個聲明一行——得能印刷到同一張紙上。通常，這意味著每個函數的代碼不超過60行左右。

• 代碼的斷言密度應平均為至少每個函數有兩個斷言。斷言用于檢查異常情況，在現實執行中是永遠不會發生的。斷言必須始終是無副作用的，并且被定義為 布爾測試。如果斷言失敗，那就應該采取明確的恢復行動，例如，通過返回錯誤條件到執行失敗斷言的函數的調用者。對于任何斷言，靜態檢查工具可以證明，它永 遠不會失敗或從未違背此條規則（即，不可能通過增加無益的“assert(true)”語句來滿足此條規則）。參見：《Developing NASA’s mission software with Java》

• 數據對象必須在盡可能小的范圍內聲明。

• 非空函數的返回值必須由每個調用函數進行檢查，參數的有效性必須在每個函數內部進行檢查。

• 使用預處理器必須僅限于包含頭文件和簡單宏定義。標記粘貼，變量參數列表，以及遞歸宏調用是不允許的。所有宏必須擴展到完整的語法單位。條件編譯 指令的使用通常也是靠不住的，但無法始終避免。這意味著，我們不應該超出標準樣板，即使在大型軟件開發中，也不應該有超過一個或兩個條件編譯指令，并避免 多次包含相同的頭文件。每一次使用條件編譯指令都應該有正當理由，并在代碼中通過基于工具的檢查器標記。

• 指針的使用應當受到限制。具體地講，解引用不允許超過一個級別。指針解引用操作可能無法隱藏在宏定義或內部定義類型聲明。函數指針是不允許的。

• 從開發的***天開始，所有代碼都必須進行編譯，并且所有的編譯器警告應該在編譯器最嚴謹的設置下開啟。所有代碼都必須在這些設置沒有任何警告下進行編譯。所有代碼每日至少必須經過一臺靜態源代碼分析器檢查，當然***能夠不止一臺，并在零警告下通過分析。

***，正如Holzmann解釋的那樣：

如果你覺得這些規則看上去過于苛刻，那么請不要忘記，這是在NASA，你的生命可能就取決于它的正確性：代碼要用來控制你飛的飛機，核能量與你住的地方可能只有幾英里，或攜帶宇航員送入軌道的航天器。

這些規則正是這一行業所需的數字安全帶——畢竟，生命之重重于泰山，否則將會帶來一場浩劫……

譯文鏈接：http://www.codeceo.com/article/nasa-10-coding-commandments.html
英文原文：NASA’s ten coding commandments

歡迎發表你的看法。