編碼標準：遵守編碼標準，讓其它程式設計師明白**，減少不必要的溝通。
通常，在公司中都有編碼規範，然而這些編碼規範執行的好與壞卻很少有人關心，編碼規範有兩個大的方面作用：一是可以使**容易理解，當然這也是最主要的作用；另外就是通過有效的編碼規範可以提高程式的穩定性。下面就給大家介紹一下以前專案團隊中關於編碼規範方面的要求。
l命名規則
乙個簡單的原則，就是通過命名能夠反映變數的資料型別和含義、函式方法的使用範圍和含義。我個人覺得匈牙利命名方法還是比較適合的。比如看到
gi_find
我就知道這是乙個公用的
int變數，看到
wf_find()
我就知道這是乙個窗體函式。這樣的規則有利於在程式設計時防止資料型別的錯誤使用，自然我就不會將乙個字串賦給
gi_find
變數。 l
異常的處理
首先不要輕易使用異常的捕獲，其次要盡可能捕獲具體的異常。對於異常的處理最好能夠採用封裝的方式，大家統一使用。這樣可以保證異常處理的一致性也可以保證當異常出現時效能的穩定。 l
與效能有關的方面
這就視開發工具的不同而有具體不同的要求了，比如常見的，不要在迴圈中定義變數；對於資料庫的查詢快取與及時查詢的選擇；
sql的寫法等等。
上面只是說到了編碼規範的幾個方面，翻閱我們制定的編碼規範，我們可以看到洋洋灑灑幾十頁，可是再看看我們的程式，是否真的遵從的編碼規範呢？我看到很多**中
i,x,y
這樣的變數定義隨處可見，一會兒定義成字元型別，一會兒定義成資料型別，還有變數定義而不知道**使用了。對於編碼規範的落實，除了依靠個人素質以外，還是更應該從**檢查入手。編碼規範的養成，不但有利於專案，更有利於個人，就如同乙個人的禮儀，通過長期的培養形成了習慣之後就自然會有一種氣質，同樣的，當你養成良好的編碼習慣後，無論走到**別人看到你的**，先不說程式思路有多好，光看編寫風格就可以看出你是否經過正規的實踐。
解讀極限程式設計的十二大原則 計畫的制定
計畫的制定 包括客戶選擇的專案大小 程式功能的優先順序 各個版本的合成和發布日期。曾經聽說過乙個關於專案經理的笑話 接手乙個專案，領導問專案需要多長時間，我們的專案經理拍拍腦袋說出乙個時間節點。領導說這個任務很緊張啊，能不能快一點 再加上一些威逼利誘的話 專案經理繼續拍拍腦袋說出乙個時間節點 就這樣...
關於《物件導向六大原則》的解讀
目錄 一 srp 單一職責原則 single responsibility priciple 二 ocp 開閉原則 open close principle 讓程式更穩定靈活 三 lsp 黎克特制替換原則 liskov substitution principle 讓程式擴充套件性更好 四 dip ...
設計原則 物件導向程式設計的六大原則
出處 一 單一職責原則 全稱 single responsibility principle 說明 就乙個類而言，應該只專注於做一件事和僅有乙個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有乙個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我...