美國航天局的十大編碼戒律

digital

美國航空航天局（NASA，以下皆用英文簡稱）有一套自己的編碼標准，以確保所有NASA應用的代碼質量和安全。這些標准漸漸演變适用於廣大的軟件開發行業。
代碼安全規則
JPL（噴氣推進實驗室）的首席科學家Gerard J. Holzmann表示，甚至是關鍵應用的代碼質量也因为大量任意的規則和不一致的准則而受害。這也是为什麼實驗室要發布編碼十誡來管轄所有NASA軟件的原因。

Holzmann和團隊在設計這些軟件開發規則時，時刻謹記代碼的安全問題。該規則明確寫明是關於C語言的——C語言是NASA用於備份關鍵安全代碼的支柱語言，有着悠久的曆史和廣泛的工具支持。不過，這些也可應用於其他大多數編程語言：
限制所有代碼为簡單的控制流結構——不使用goto語句，不使用setjmp和longjmp結構以及直接或間接的遞歸。
所有的循環必須有固定的上限。用檢查工具靜態地證明，預先設定的上限是一個循環不能超過的迭代次數，在數學上是可能的。如果循環限制不能靜態證明，那麼就違背了此條規則。
初始化後不要使用動態內存分配。
一個函數在標准参考格式下——每個語句一行，每個聲明一行——得能印刷到同一張紙上。通常，這意味着每個函數的代碼不超過60行左右。
代碼的斷言密度應平均为至少每個函數有兩個斷言。斷言用於檢查異常情況，在現實執行中是永遠不會發生的。斷言必須始終是無副作用的，並且被定義为 布爾測試。如果斷言失敗，那就應該采取明確的恢复行動，例如，通過返回錯誤條件到執行失敗斷言的函數的調用者。對於任何斷言，靜態檢查工具可以證明，它永 遠不會失敗或從未違背此條規則（即，不可能通過增加無益的“assert(true)”語句來滿足此條規則）。参見：《Developing NASA’s mission software with Java》
數據對象必須在盡可能小的範圍內聲明。
非空函數的返回值必須由每個調用函數進行檢查，参數的有效性必須在每個函數內部進行檢查。
使用預處理器必須僅限於包含頭文件和簡單宏定義。標記粘貼，變量参數列表，以及遞歸宏調用是不允許的。所有宏必須擴展到完整的語法單位。條件編譯 指令的使用通常也是靠不住的，但無法始終避免。這意味着，我們不應該超出標准样板，即使在大型軟件開發中，也不應該有超過一個或兩個條件編譯指令，並避免 多次包含相同的頭文件。每一次使用條件編譯指令都應該有正當理由，並在代碼中通過基於工具的檢查器標記。
指針的使用應當受到限制。具體地講，解引用不允許超過一個級別。指針解引用操作可能無法隱藏在宏定義或內部定義類型聲明。函數指針是不允許的。
從開發的第一天開始，所有代碼都必須進行編譯，並且所有的編譯器警告應該在編譯器最嚴謹的設置下開启。所有代碼都必須在這些設置沒有任何警告下進行編譯。所有代碼每日至少必須經過一台靜態源代碼分析器檢查，當然最好能夠不止一台，並在零警告下通過分析。
最後，正如Holzmann解釋的那样：
如果你覺得這些規則看上去過於苛刻，那麼請不要忘記，這是在NASA，你的生命可能就取决於它的正確性：代碼要用來控制你飛的飛機，核能量與你住的地方可能只有幾英裏，或攜帶宇航員送入軌道的航天器。
這些規則正是這一行業所需的數字安全帶——畢竟，生命之重重於泰山，否則將會帶來一場浩劫……

英文原文：NASA’s ten coding commandments