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

>>> 技術話題—商業文明的嶄新時代 >>>

簡體傳統

　　英文原文：NASAs ten coding commandments

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

　　代碼安全規則

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

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

限制所有代碼為簡單的控制流結構不使用 goto 語句，不使用 setjmp 和 longjmp 結構以及直接或間接的遞歸。
所有的循環必須有固定的上限。用檢查工具靜態地證明，預先設定的上限是一個循環不能超過的迭代次數，在數學上是可能的。如果循環限制不能靜態證明，那么就違背了此條規則。
初始化后不要使用動態內存分配。
一個函數在標準參考格式下每個語句一行，每個聲明一行得能印刷到同一張紙上。通常，這意味著每個函數的代碼不超過 60 行左右。
代碼的斷言密度應平均為至少每個函數有兩個斷言。斷言用于檢查異常情況，在現實執行中是永遠不會發生的。斷言必須始終是無副作用的，并且被定義為布爾測試。如果斷言失敗，那就應該采取明確的恢復行動，例如，通過返回錯誤條件到執行失敗斷言的函數的調用者。對于任何斷言，靜態檢查工具可以證明，它永遠不會失敗或從未違背此條規則（即，不可能通過增加無益的assert (true)語句來滿足此條規則）。參見：《Developing NASAs mission software with Java》
數據對象必須在盡可能小的范圍內聲明。
非空函數的返回值必須由每個調用函數進行檢查，參數的有效性必須在每個函數內部進行檢查。
使用預處理器必須僅限于包含頭文件和簡單宏定義。標記粘貼，變量參數列表，以及遞歸宏調用是不允許的。所有宏必須擴展到完整的語法單位。條件編譯指令的使用通常也是靠不住的，但無法始終避免。這意味著，我們不應該超出標準樣板，即使在大型軟件開發中，也不應該有超過一個或兩個條件編譯指令，并避免多次包含相同的頭文件。每一次使用條件編譯指令都應該有正當理由，并在代碼中通過基于工具的檢查器標記。
指針的使用應當受到限制。具體地講，解引用不允許超過一個級別。指針解引用操作可能無法隱藏在宏定義或內部定義類型聲明。函數指針是不允許的。
從開發的第一天開始，所有代碼都必須進行編譯，并且所有的編譯器警告應該在編譯器最嚴謹的設置下開啟。所有代碼都必須在這些設置沒有任何警告下進行編譯。所有代碼每日至少必須經過一臺靜態源代碼分析器檢查，當然最好能夠不止一臺，并在零警告下通過分析。

　　最后，正如 Holzmann 解釋的那樣：