程序的斷言密度（Assertion density）應平均保持為每個函數最少兩個斷言。斷言可用于檢查現實運行過程中本絕不應出現的異常狀況，因此應定義為Boolean測試。當斷言失敗后，應執行明確的恢復操作。

如果靜態檢查工具證明斷言絕對不會Fail或Hold，則可認為未遵守該原則。

原因：業界的代碼編寫工作統計報告顯示，通過單元測試可發現，通常我們所編寫的每10-100行代碼中至少會存在一處缺陷。隨著斷言密度的增高，攔截缺陷的機會也會增大。

斷言的另一個重要之處在于，它是防御性編程（Defensive coding）策略的重要組成部分。我們可以使用斷言驗證函數執行前后的狀況，函數的執行參數和返回值，以及循環不變式（Loop-invariant）。在完成性能關鍵代碼的測試工作后，可將斷言選擇性地禁用。

原則6 – 以最小范圍級別聲明數據對象（Declare Data Objects at Smallest Level of Scope）

該原則同時也是數據隱蔽（Data hiding）的基本原則。所有數據對象均必須以盡可能最小的范圍級別進行聲明。

原因：如果某對象不在范圍內，意味著其值將無法引用或已損壞。該原則不鼓勵出于多種可能導致故障診斷工作變得更復雜的互斥意圖重用變量。

原則7 – 檢查參數和返回值（Check Parameters and Return Value）

應在每次調用函數后檢查非空函數的返回值，并應在每個函數內部檢查參數的合法性。

在最嚴格的形式下，該原則意味著就算printf語句和文件close語句的返回值也應進行檢查。

原因：如果對一個錯誤結果的響應與對成功結果的響應本不應有任何區別，那么很明顯需要檢查返回值。通常對close和printf的調用便符合這種情況。此時一種可行的方法是將函數的返回值明確拋出給void，這意味著開發者明確（而非意外地）決定忽略該返回值。

原則8 – 限制預處理程序的使用（Limited Use of Preprocessor）

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

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

有關條件編譯的注意事項同樣很重要 – 就算只使用10個條件編譯指令，代碼也有會產生1024（2^10）個可能的版本，這會導致測試工作量劇增。

原則9 – 限制指針的使用（Limited Use of Pointers）

指針的使用必須加以限制。通常只允許不超過一層的解引用（Dereferencing）。指針解引用操作不應隱藏在typedef聲明或宏定義內部。此外函數指針也是不允許使用的。

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

原則10 – 編譯所有代碼（Compile all Code）

從開發工作第一天開始時，就必須對所有代碼進行編譯。必須啟用編譯器的警告功能，并使用最細致的檢查選項。代碼必須能通過這樣的設置在不產生任何警報的情況下順利編譯完成。

所有代碼必須每天一次、使用至少一種（多種則更好）最新型的靜態源代碼分析器進行檢查，并且必須順利通過分析器的整個檢查過程而不產生任何警告。

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

如果編譯器或靜態分析器遇到問題，導致問題/錯誤的代碼必須重寫，這樣才能進一步改善代碼質量。

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

此文在Reddit引發了熱烈的討論，現將部分有價值內容摘錄如下：

本文的很多原則提到使用靜態代碼分析器進行分析是一種更簡單可靠的辦法。如果我在開發C或C++代碼，有什么好用的免費靜態代碼分析器嗎？一方面我想看看這些分析器的工作效果，另一方面，我一直在使用另一個極為糟糕的分析器，想對比一下來了解原本使用的分析器到底有多糟糕。

我覺得有必要提醒大家，本文所說的“安全關鍵程序”是一種面向特定領域的術語。每次網上流傳類似這樣的東西時，大家都會試圖將相關內容應用在一般常規用途的軟件中，但實際上除非你的軟件中出現的無法處理的異常真的會致命，否則并不需要如此嚴格（也許也不應該這樣做，因為大部分此類原則會在代碼可讀性和可維護性方面造成不小的麻煩）。

原則3 – 不使用動態內存分配

這條讓我大吃一驚。我很好奇，如果不使用動態內存分配，你到底如何編寫哪怕很小規模的程序！是否就只在程序運行時分配一大塊內存，隨后程序的所有執行都在這塊內存中進行？

我倒是對于NASA使用C語言感覺驚訝，我本想著他們會使用Ada之類的東西。

這些原則中很多原則與我在ASEA（現ABB）擔任開發者時所遵守的原則是相同的，拋開這些不談，同時拋開有關預處理程序的原則不談，我們當時主要使用Pascal，對于遞歸函數也制訂了相應的原則。我編寫了一個預處理程序，這樣就可以保證開發者能夠獲得恰當的聲明，而無需擔心這些問題，此外我們還會按照標準設置程序代碼的縮進和格式，畢竟每個程序員在代碼格式方面都有一些個人偏好。所有程序都有必要在這些問題方面由其他程序員進行交叉檢查。

他們為什么不把這些原則強制應用到編譯器中？可以通過 -WNasa 或其他類似的東西告訴開發者是否違反了這些原則。此外還需要使用 std lib C 來維護這些嚴格的原則。

建議挺好，就是不明白為什么不用自動化的方法來應用（或者他們正是這樣做的？）