NASA頂級程序員編程十大原則

導讀	引言： 你知道 NASA 頂級程序員如何編寫關鍵任務代碼麼？爲了確保代碼更清楚、更安全、且更容易理解，NASA 的噴氣推動實驗室制定了 10 條編碼規則。

NASA 的開發者是編程界最有挑戰性的工做之一。他們編寫代碼並將開發安全的關鍵任務應用程序做爲其主要關注點。

在這種情形下，遵照一些嚴格的編碼規則是重要的。這些規則覆蓋軟件開發的多個方面，例如軟件應該如何編碼、應該使用哪些語言特性等。

儘管很難就一個好的編碼標準達成共識，NASA 的噴氣推動實驗室（JPL）遵照一個編碼規則，其名爲「十的次方：開發安全的關鍵代碼的規則」。

因爲 JPL 長期使用 C 語言，這個規則主要是針對於 C 程序語言編寫。可是這些規則也能夠很容地應用到其它的程序語言。

該規則由 JPL 的首席科學家 Gerard J. Holzmann 制定，這些嚴格的編碼規則主要是聚焦於安全。

NASA 的 10 條編寫關鍵任務代碼的規則：

1.限制全部代碼爲極爲簡單的控制流結構 — 不用 goto 語句、setjmp 或 longjmp 結構，不用間接或直接的遞歸調用。

2.全部循環必須有一個固定的上限值。必須能夠被某個檢測工具靜態證明，該循環不能達到預置的迭代上限值。若是該上限值不能被靜態證明，那麼能夠認爲違背該原則。

3.在初始化後不要使用動態內存分配。

4.若是一個語句一行、一個聲明一行的標準格式來參考，那麼函數的長度不該該比超過一張紙。一般這意味着每一個函數的代碼行不能超過 60。

5.代碼中斷言的密度平均低至每一個函數 2 個斷言。斷言被用於檢測那些在實際執行中不可能發生的狀況。斷言必須沒有反作用，並應該定義爲布爾測試。當一個斷言失敗時，應該執行一個明確的恢復動做，例如，把錯誤狀況返回給執行該斷言失敗的函數調用者。對於靜態工具來講，任何能被靜態工具證明其永遠不會失敗或永遠不能觸發的斷言違反了該規則（例如，經過增長無用的 assert(true) 語句是不可能知足這個規則的）。

6.必須在最小的範圍內聲明數據對象。

7.非 void 函數的返回值在每次函數調用時都必須檢查，且在每一個函數內其參數的有效性必須進行檢查。

8.預處理器的使用僅限制於包含頭文件和簡單的宏定義。符號拼接、可變參數列表（省略號）和遞歸宏調用都是不容許的。全部的宏必須可以擴展爲完整的語法單元。條件編譯指令的使用一般是晦澀的，但也不老是可以避免。這意味着即便在一個大的軟件開發中超過一兩個條件編譯指令也要有充足的理由，這超出了避免屢次包含頭文件的標準作法。每次在代碼中這樣作的時候必須有基於工具的檢查器進行標記，並有充足的理由。

9.應該限制指針的使用。特別是不該該有超過一級的解除指針引用。解除指針引用操做不能夠隱含在宏定義或類型聲明中。還有，不容許使用函數指針。

10.從開發的第一天起，必須在編譯器開啓最高級別警告選項的條件下對代碼進行編譯。在此設置之下，代碼必須零警告編譯經過。代碼必須利用源代碼靜態分析工具天天至少檢查一次或更屢次，且零警告經過。
關於這些規則，NASA 是這麼評價的：

這些規則就像汽車中的安全帶同樣，剛開始你可能感到有一點不適，可是一段時間後就會養成習慣，你會沒法想象不使用它們的日子。

做者簡介：

Adarsh Verma 是 Fossbytes 的共同創始人，他是一個使人尊敬的企業家，他一直對開源、技術突破和徹底保持密切關注。能夠經過郵件聯繫他 — adarsh.verma@fossbytes.com

via: https://fossbytes.com/nasa-coding-programming-rules-critical/

做者：Adarsh Verma 譯者：penghuster 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

原文來自： http://www.linuxprobe.com/program-principle.html