關於程式設計原則，實際上並沒有一套統一的原則可以適用於所有的系統，不同應用場景、不同架構的系統，對於程式設計原則的要求相差還是比較大，看看以下著名的17條unix程式設計原則和nasa 的10條安全編碼準則，大家就可想而知了。當然，兩者並非對比，而是側重點不同。
1、模組化原則（rule of modularity）
開發人員應該使用定義良好的介面連線簡單的部分來構建程式，所以問題是本地的，部分程式可以在未來的版本中替換以支援新的功能。此規則旨在節省除錯複雜，長期且不可讀的**的時間。
2、清晰原則（rule of clarity）
開發人員應該編寫清晰的程式，就好像最重要的溝通是向開發人員讀取和維護程式，而不是計算機。這個規則的目的是使**在將來的**中盡可能易讀和易理解。
3、和解原則（rule of composition）
開發人員應該編寫能夠與其他程式輕鬆通訊的程式。這條規則的目的是讓開發人員把專案分解成小而簡單的程式，而不是過於複雜的單片程式。
4、分離規則（rule of separation）
開發者應該將程式的機制與程式的策略分開;一種方法是將程式分成與該介面通訊的前端介面和後端引擎。這條規則旨在通過允許改變策略，盡可能降低操作機制的不穩定性來防止錯誤引入。
5、簡單規則（rule of simplicity），
開發人員應該設計簡單的方法，通過尋找方法將程式系統分解成小而直接的合作件。這條規則的目的是阻止開發者寫作「複雜而美麗的複雜性」，這是現實中容易出錯的程式。
6、簡約規則（rule of parsimony）
開發人員應該避免編寫大型程式。這一規則的目的是防止由於專案的所有者不願拋棄顯著的大量工作而導致失敗或次優方法的過度投資。較小的程式不僅易於編寫，優化和維護，棄用時更容易刪除。
7、透明度原則（rule of transparency）
開發人員應該設計可見性和可發現性，通過編寫這樣一種方式，他們的思維過程可以清楚地被未來的專案開發人員所看到，並使用輸入和輸出格式，以便識別有效輸入和正確輸出。此規則旨在減少除錯時間並延長程式的使用壽命。
8、穩健性規則（rule of robustness）
開發人員應該通過設計透明和可發現性來設計強大的程式，因為易於理解的**更容易對複雜程式中無法預見的意外情況進行壓力測試。此規則旨在幫助開發人員構建強大，可靠的產品。
9、表示規則（rule of representation）
開發人員在面對選擇時應該選擇使資料更複雜，而不是程式的邏輯，因為與複雜的邏輯相比，人類更容易理解複雜的資料。這條規則的目的是使任何開發專案的開發人員都可以使程式更易讀，從而使程式得以維護。
10、最小驚喜規則（rule of least surprise）
開發人員應該根據潛在使用者的預期知識設計程式。例如，計算器程式中的「+」應該總是指「加法」。該規則旨在鼓勵開發人員構建易於使用的直觀產品。
11、沉默的規則（rule of silence）
開發人員應該設計程式，以免列印不必要的輸出。這個規則旨在允許其他程式和開發者從程式的輸出中挑出他們需要的資訊，而不必分析冗長。
12、修理規則（rule of repair）
開發人員應該設計失敗的程式，易於本地化和診斷，換句話說就是「失敗」。這條規則旨在防止程式的錯誤輸出成為輸入，並破壞未被檢測到的其他**的輸出。
13、經濟規則（rule of economy）
開發人員應該重視開發人員在機器上的時間，因為與上世紀70年代的**相比，今天的機器週期相對便宜。這條規則旨在降低專案的開發成本。
14、生成規則（rule of generation）
開發人員應該避免手動編寫**，而是編寫抽象的高階程式來生成**。此規則旨在減少人為錯誤並節省時間。
15、優化規則（rule of optimization）
開發人員應該在打磨軟體之前製作原型。這條規則旨在防止開發者花費太多時間來獲得邊際收益。
16、規則的多樣性（rule of diversity）
開發者應該設計他們的程式是靈活的，開放的。這條規則的目的是使程式更加靈活，使其能夠以開發者所期望的方式使用。
17、可擴充套件性規則（rule of extensibility）
開發人員應該通過使其協議可擴充套件來設計未來，允許輕鬆外掛程式，而無需修改其他開發人員的程式架構。
由nasa的首席科學家gerard j. holzmann制定
1、簡化控制流程
使用盡可能精簡的控制流程設計： 不要使用 setjmp 或 longjmp、goto 語句，以及直接或間接的遞迴呼叫。
2、使用固定的迴圈次數上限
所有的迴圈必須有乙個固定的上限。 必須可以被檢測工具靜態地證實，該迴圈的迭代器不會超出上限值，如果不能被靜態地證實，則可以認為違背該規則。
3、不使用動態記憶體分配
不要在初始化完成後進行動態記憶體分配。
4、不使用冗長的函式
要求函式的**長度按照每個宣告佔一行、每個語句佔一行這樣的標準參考格式，能在一頁紙上列印出來。這意味著函式的**不應超過60行。
5、低斷言密度
**中的斷言密度（assertion density）應低至平均每個函式2個斷言。斷言用於檢查實際執行過程中絕不應出現的異常狀況，必須定義為boolean測試。當斷言失敗時，應執行明確的恢復操作。如果靜態檢查工具發現斷言永遠不可能失敗或永遠不會被觸發，則可認為未遵守該原則。
6、以最小範圍級別宣告資料物件
該原則同時也是資料隱蔽（data hiding）的基本原則。所有資料物件必須以盡可能小的範圍級別進行宣告。
7、檢查引數和返回值
應在每次呼叫函式後檢查非void函式的返回值，並在每個函式內部檢查引數的有效性。
8、限制預處理程式的使用
預處理程式（preprocessor）只能在標頭檔案和巨集定義中使用。遞迴的巨集呼叫、符號拼接，以及可變引數列表均不允許使用。
通常不建議使用條件編譯指令，如果**中不能夠避免時，必須有基於工具的檢查器進行標記，並有充足的理由。
9、限制指標的使用
必須限制指標的使用，不允許有超過一級的指標解引用操作。指標解引用操作不能隱藏在typedef型別宣告或巨集定義中。不允許使用函式指標。
10、編譯所有**
從開發工作第一天開始，就必須對所有**進行編譯。必須啟用編譯器的警告功能，並使用最細緻的檢查選項。在此設定之下，**必須零警告編譯通過。**必須使用源**靜態分析工具，每天檢查一次以上，且零警告通過。
程式設計原則
避免重複原則 dry don t repeat yourself 程式設計的最基本原則是避免重複。在程式 中總會有很多結構體，如迴圈 函式 類等等。一旦你重複某個語句或概念，就會很容易形成乙個抽象體。抽象原則 abstraction principle 與dry原則相關。要記住，程式 中每乙個重要的...
程式設計原則
結構化設計的兩個基本原則 高內聚，低耦合 在物件導向的設計中，目標就是設計出高內聚 低耦合的程式。聚合 cohesion 聚合是乙個模組內部各成分之間相關聯程度的度量 聚合是對乙個模組內部的度量，因為是對乙個模組內部的度量，所以聚合也成為內聚，這裡的模組是廣義上的模組，它代表的可能是乙個子系統，或者...
軟體測試原則
1.測試證明軟體存在缺陷 無論執行什麼樣的測試操作都能證明當前軟體是有缺陷的 2.不能執行窮盡測試 有些功能是沒有辦法將所有的測試情況都邏輯出來，所以任何的測試操作都有結束的時間 3.缺陷存在群集現象 對於軟體功能說，核心功能佔20 非核心80 在實際工作中我們會集中測試20 的核心功能，所以這個部...