美國太空總署（NASA，以下皆用英文簡稱）有一套自己的編碼標準，以確保所有 NASA 應用的代碼質量和安全。這些標準漸漸演變適用於廣大的軟體開發行業。
- 代碼安全規則
JPL（噴氣推進實驗室）的首席科學家 Gerard J. Holzmann 表示，甚至是關鍵應用的代碼質量也因為大量任意的規則和不一致的準則而受害。這也是為什麼實驗室要發布「編碼十誡」來管轄所有 NASA 軟體的原因。
Holzmann 和團隊在設計這些軟體開發規則時，時刻謹記代碼的安全問題。該規則明確寫明是關於 C 語言的——C 語言是 NASA 用於備份關鍵安全代碼的支柱語言，有著悠久的歷史和廣泛的工具支持。不過，這些也可應用於其他大多數編程語言：
1. 限制所有代碼為簡單的控制流結構——不使用 goto 語句，不使用 setjmp 和 longjmp 結構以及直接或間接的遞歸。
2. 所有的循環必須有固定的上限。用檢查工具靜態地證明，預先設定的上限是一個循環不能超過的迭代次數，在數學上是可能的。如果循環限制不能靜態證明，那麼就違背了此條規則。
3. 初始化後不要使用動態內存分配。
4. 一個函數在標準參考格式下——每個語句一行，每個聲明一行——得能印刷到同一張紙上。通常，這意味著每個函數的代碼不超過 60 行左右。
5. 代碼的斷言密度應平均為至少每個函數有兩個斷言。斷言用於檢查異常情況，在現實執行中是永遠不會發生的。斷言必須始終是無副作用的，並且被定義為布爾測試。如果斷言失敗，那就應該採取明確的恢復行動，例如，通過返回錯誤條件到執行失敗斷言的函數的調用者。對於任何斷言，靜態檢查工具可以證明，它永遠不會失敗或從未違背此條規則（即，不可能通過增加無益的“assert(true)”語句來滿足此條規則）。參見：《Developing NASA’s mission software with Java》
6. 數據對象必須在盡可能小的範圍內聲明。
7. 非空函數的返回值必須由每個調用函數進行檢查，參數的有效性必須在每個函數內部進行檢查。·
8. 使用預處理器必須僅限於包含頭文件和簡單宏定義。標記粘貼，變量參數列表，以及遞歸宏調用是不允許的。所有宏必須擴展到完整的語法單位。條件編譯指令的使用通常也是靠不住的，但無法始終避免。這意味著，我們不應該超出標準樣板，即使在大型軟件開發中，也不應該有超過一個或兩個條件編譯指令，並避免多次包含相同的頭文件。每一次使用條件編譯指令都應該有正當理由，並在代碼中通過基於工具的檢查器標記。
9. 指針的使用應當受到限制。具體地講，解引用不允許超過一個級別。指針解引用操作可能無法隱藏在宏定義或內部定義類型聲明。函數指針是不允許的。
10. 從開發的第一天開始，所有代碼都必須進行編譯，並且所有的編譯器警告應該在編譯器最嚴謹的設置下開啟。所有代碼都必須在這些設置沒有任何警告下進行編譯。所有代碼每日至少必須經過一台靜態源代碼分析器檢查，當然最好能夠不止一台，並在零警告下通過分析。
最後，正如 Holzmann 解釋的那樣：
如果你覺得這些規則看上去過於苛刻，那麼請不要忘記，這是在 NASA，你的生命可能就取決於它的正確性：代碼要用來控制你飛的飛機，核能與你住的地方可能只有幾英里，或攜帶太空人員送入軌道的航天器。
這些規則正是這一行業所需的數位安全帶——畢竟，生命之重重於泰山，否則將會帶來一場浩劫……
歡迎發表你的看法。
英文原文：NASA's ten coding commandments；翻譯作者：碼農網 –小峰（本文轉載自合作夥伴《碼農網》；未經授權，不得轉載）
──
- 延伸閱讀
YC 創辦人Paul Graham：當政府問「如何建造矽谷」之時，就大概保證會失敗
【血鑽石手機版】你所使用的手機，可能沾滿了非洲勞工的鮮血
【TED 演講】Uber CEO 的初衷：把更多的人擠進更少的車子裡
