1. dry: 不要重複你自己（don』t repeat yourself）
dry是一條最容易理解但又是相對比較難以應用的原則。它是指當你在兩處或者更多的地方發現相似**時，我們應當把它們抽象成乙個新的函式，在之前重複的地方呼叫新的函式並帶上適當的引數。
dry也許是最普遍的一條程式設計原則，我從未發現乙個開發人員認為編寫重複的**是件好事。但是我發現一些開發人員在編寫單元測試時忘記了這條原則，例如：設想一下你改變了乙個類的介面，之前已經為這個類編寫了很多的單元測試，如果你沒有應用dry原則，這時你需要手動去修改所有使用這個類介面的呼叫，來與每乙個測試例項的新簽名匹配。
2. 編寫短小的函式/方法
有三個非常好的理由，選擇編寫短小的函式。
編者注：松耦合：在軟體領域中，「耦合」一般指軟體元件之間的依賴程度。耦合度松的軟體會有較好的擴充套件性。
3. 給類、函式和變數使用好的命名
直接使用其他開發者的**而不需要閱讀說明文件，沒有什麼比這更好的事情了，因為**中的類名、函式名已經能夠告訴我們所有需要的資訊。所以，採用這種方法，每次在為你的**中任何元素進行命名的之前請花上幾秒鐘（思考），這會讓大家的生活變得更輕鬆。
4. 為每個類分配正確的職責
乙個類只承擔乙個職責（單一權責），聽起來和有些人知道的solid原則很相似，但是這裡不是指任意的職責，而是正確的職責。所以，如果我們要設計乙個顧客類，我們不會給它建立乙個銷售的行為，我們只會讓它處理所有與乙個客戶相關的資料。
編者注：solid：物件導向設計的五項原則 （是srp單一職責原則、ocp開閉原則、lsp李式代換原則、isp依賴反轉原則和 dip介面分離原則，首字元的縮寫)。
5. 保持**的條理性
**條理性分兩個層次
6. 編寫很多的單元測試
測試越多越好，它們是所有**變動的安全保證，我們會在將來的某一天需要執行這些測試**。
7. 盡早且經常地重構**（refactor often and sooner）
軟體開發是乙個持續發現的過程，為了編寫保持與新增/改變的需求匹配的高質量**，隨著開發的進行，重構**是必不可少的。由於重構是一項帶有風險的任務，需要有兩個主要的前提條件，來避免由於重構給系統引入新的錯誤。
8. 注釋是惡魔
這條特殊戒律有一點爭議，我們大多數人學到的是「注釋是乙個好的習慣」，並且在一段晦澀的**中有一段注釋會比僅僅只有**好的多，這裡我的觀點是：給晦澀的**加注釋還不如僅僅留下**，只需要重構這段**直到它變得可讀為止。（編註：當然了，除了作者說的這種型別的**，在其他情況下，還是得新增必要的注釋，這不僅方便自己日後檢視，更有利於後來者維護，請參閱《提高**可讀性的10個注釋技巧 》一文。
9. 要面向介面程式設計，不要面向實現程式設計（code to an inte***ce, not to an implementation）
這是一條經典的原則，面向介面程式設計會讓我們從實現的細節中解放出來，我們只要定義乙個協議，並且依據協議呼叫定義的操作，期望（對方，即被呼叫的**）能把實際的實現或者執行時態的實現傳遞給我們的**。
10. 對**進行複查
我們都會犯錯誤，沒有什麼能比請別人對我們**做乙個非正式快速複查更好的辦法來查詢錯誤了。最好不要等到**都完成以後再複查，當某些重要部分的**完成後，或者離上一次複查相隔幾天之後，就進行複查。
程式設計好習慣
我們在編碼的時候總是希望能寫出風格良好，清晰 健壯的程式，把 當成一件藝術品來看待 來雕琢，讓 coding成為一種藝術。看了很多大牛關於程式設計風格與修養方面的文章，很受啟發，結合自己體會，簡錄幾條，提醒自己時刻注意。1.引數檢查 對於有引數的函式，首先要對引數的合法性進行檢查。可以利用asser...
C 程式設計好習慣
1.不要在建構函式中做初始化操作 要求類 尤其是對外介面類 提供init 函式，在該函式中進行相關初始化操作，初始化失敗能夠返回錯誤碼。可以規避問題 建構函式中難以返回錯誤碼，外部呼叫者無從判斷初始化結果。當該類作為全域性變數使用時，構造函式呼叫發生在main 函式執行之前，出現問題難以追蹤。2.所...
15個程式設計好習慣
編者按 這是國外程式設計師al katib總結的一些程式設計習慣。1.動手編碼之前，你需要對要編碼實現的解決方案有乙個正式的或粗略的設計。永遠不要在沒有任何設計的前提下就開始編碼，除非所編 不重要。2.優秀的 文件跟程式語言知識一樣重要。在 原始檔中，為每個主要的 段新增注釋，解釋 的基本邏輯。最好...