c#編碼規範

　做爲軟件開發者，咱們能夠開發低等級的軟件，但不能開發低質量的軟件。因此，如何實施質量保證，是咱們關注的主要問題之一，而編碼規範則是實施質量保證的第一步。

　　編碼規範已經成爲一個老生常談的問題，幾乎每一個項目，每家公司都會定義本身的編碼規範。但在真正實施時，卻在有意或無心地違背編碼規範。程序員，不喜歡改變本身的編程習慣。加之，管理者對質量控制不足，致使編碼規範每每形同虛設。有些人會認爲：遵照編碼規範不能給項目帶來利益，也不能讓客戶看到咱們爲此付出的努力，其徹底是團隊自發的行爲，沒有必要作硬性的要求。還有些人有更好的理由：編碼規範會破壞創造性和程序質量。我認爲，編碼規範，在軟件構件以及項目管理中，甚至是我的成長方面，都發揮着重要的做用，好的編碼規範是提升咱們代碼質量的最有效的工具之一。

一 編碼規範的做用

• 提升可讀性 「任何一個傻瓜都能寫出計算機能夠理解的代碼，惟有寫出人類容易理解的代碼，纔是優先的程序員。」編碼規範，幫助咱們寫出人類容易理解的代碼，它爲咱們提供了最基本的模板，良好的編碼風格，使代碼具備必定的描述性，能夠經過名字來獲取一些須要IDE才能獲得的提示，如可訪問性、繼承基類等。
• 統一全局，促進團隊協做 開發軟件是一個團隊活動，而不是我的的英雄主義。編碼規範，要求團隊成員遵照這一統一的全局決策，這樣成員之間能夠輕鬆地閱讀對方的代碼，全部成員正以一種清晰而一致的風格進行編碼。並且，開發人員也能夠集中精力關注他們真正應該關注的問題——自身代碼的業務邏輯，與需求的契合度等局部問題。
• 有助於知識傳遞，加快工做交接 風格的類似性，能讓開發人員更迅速，更容易理解一些陌生的代碼，更快速地理解別人的代碼。由於，他和你的代碼風格是同樣的，你沒有必要對他的一些個性化風格進行揣測。這樣的好處是開發人員能夠很快的接手項目組其餘成員的工做，快速完成工做交接。
• 減小名字增生，下降維護成本 在沒有規範的狀況下，和容易爲同一類型的實例起不一樣的名字。對於之後維護這些代碼程序員來講會產生疑惑。
• 強調變量之間的關係，下降缺陷引人的機會 命名能夠表示必定的邏輯關係，是開發人員在使用時保持警戒，從而必定程度上減小缺陷被引人的機會。
• 提升程序員的我的能力 不能否認，每一個程序員都應該養成良好的編碼習慣，而編碼規範無疑是教材之一。從一個程序員的代碼自己能看出不少東西。因此，即使是爲了自身發展，做爲程序員也沒有理由抵制這種規則的存在。你可能沒有認識到，咱們正默默地得益於編碼規範。

二 編碼規範不是「物神」

　　在高質量的軟件中，你能夠看到「架構的概念完整性」與「底層實現」之間的關係。「實現」與「架構」必須是清晰一致的，這種內在的、固有的一致性，須要編碼規範來維繫。若是沒有這種統一的約定，那麼咱們作出的東西可能會充斥着各類不一樣的風格，顯得混亂且難以理解。團隊成員之間可能很不理解彼此之間的想法，甚至是相互抨擊。各類編碼風格上的差別會不斷擴大，而代碼質量則不斷降低。並且，團隊成員會花費時間在理解不一樣編程風格之間的差別，而沒有專一於真正應該解決的問題。這樣的時間消耗是難以接受的。因此，在每個高質量代碼的背後，必定存在着一份優秀的編碼規範。

　　然而，也必須認識到編碼規範不是「物神」。編碼規範僅僅是一個全局性質的規範，它只不過是一種編程約定，不能解決更深層次的問題。就像一篇格式漂亮但內容糟糕的論文不能被髮表同樣，你不能僅靠一個規範來擺脫軟件做坊。並且，在編碼規範中不宜包含那些冗長的開發技巧。我認爲，對於代碼是最佳實踐應該是代碼審查所要解決的，應該避免將編碼規範寫成一部關於重構的教科書。

三 編寫編碼規範的一些建議

　　如下是我對定義編碼規範的一些建議：

• 求同存異 不要妄圖改變組織的編碼習慣，除非有絕對合理的理由，不然仍是以民主爲主，畢竟你沒有權利要求全部人都沿用你的編碼習慣。
• 定義編碼規範越早越好 也早使用編碼規範，也早享受其帶來的好處。
• 將規範分爲強制部分和推薦部分 求同存異的具體實現。將最基本的規範列放在強制部分，全部成員必須遵照；將好的但不重要的習慣列在推薦部分，開發人員能夠根據本身習慣選擇是否使用。
• 編碼規範不要太長 太長的文檔沒人看，全部人都同樣，除了禮品單和工資單沒人願意看長的東西，因此編碼規範必須精煉，最好是隻有2~3頁，讓開發人員能夠打印出來隨時查看。
• 必須是約定俗成的 規範必須是行業中約定俗成的，不要有什麼個性化發揮。

四 編碼規範參考

　　我本人不太推薦制定過細的編碼規範。制定編碼規範是爲了加強代碼的可讀性，畢竟代碼的結構纔是主要關注問題，因此個人編碼規範仍是比較簡短的。裏面只是對可能會破壞編碼風格的行爲進行約束，而沒有細化到「空行」甚至「空格」的級別。　

編碼規範

一 命名空間

　　<公司名稱>.(<產品名稱>|<相關技術>)[.<用途>] [.<子命名空間>]

二 代碼風格

• 花括號「{}」不容許省略，即便只有一段代碼。
• 不容許省略訪問修飾符。
• 類型默認是密封的。
• 不容許公開字段。
• 使用括號「()」來強調運算符優先級。

三 命名規範

（一） 類、結構和接口的命名

• 使用名詞或名詞短語。
• 使用Pascal方式。
• 在接口名稱前加上前綴「I」。
• 考慮在派生類末尾使用基類的名字。
• 若是該類僅僅爲了實現某個接口，那麼請保持其與接口命名的統一。
• 若是從.NET 框架中存在的類型派生的類型，應該遵循如下規範：

基類	派生類
System.Attribute	要給自定義的特性添加「Attribute」後綴
System.Delegate	要給用於事件處理的委託添加「EventHandler」後綴  要給用於事件處理以外的那些委託添加「Callback」後綴   不要給委託添加「Delegate」後綴
System.EventArgs	要添加「EventArgs」後綴
System.Exception	要添加「Exception」後綴
IDictionary，IDictionary<T,V>	要添加「Dictionary」後綴
IEnumerable，ICollection，IList，  IEnumerable<T>，ICollection<T>，IList<T>	添加「Collection」後綴
System.IO.Stream	添加「Stream」後綴
CodeAccessPermission，IPermission	添加「Permission」後綴

（二） 成員的命名

成員	大小寫	規範
方法	Pascal（公開）、Camel（私有）	用動詞或動詞短語命名
屬性	Pascal	用名詞、名詞短語或形容詞來命名   集合屬性應該使用複數形式，而不是添加後綴   用「Is」、「Can」、「Has」等表示布爾屬性  能夠用屬性的類型名來命名屬性
事件	Pascal	使用動詞或動詞短語來命名事件  用如今時和過去時來區分前置和後置事件
字段	Camel（私有）	要用名詞、名詞短語或形容詞來命名  不要加任何前綴

（三） 參數的命名

• Camel風格。
• 要使用left和right來命名重載的二元操做符的參數——若是參數沒有具體的含義。
• 要使用value來命名重載的一元操做符的參數——若是參數沒有具體的含義。
• 不要在參數中使用數字編號。
• 儘可能使用描述性的名字命名泛型類型參數，並在前面使用「T」前綴。

（四） 常量、變量的命名

• 常量——全部單詞大寫並用「_」分隔。
• 局部變量——Camel風格。

（五） 枚舉的命名

• Pascal風格。
• 使用名詞的複數形式來命名標記枚舉。
• 不要添加「Enum」或「Flag」後綴。
• 不要給枚舉類型值的名字加前綴。

（六） 資源的命名

• Pascal風格。
• 僅使用字母、數字和下劃線。
• 在命名異常消息的資源時，資源標識符應該是異常類型名加上簡短的異常標識符。

（七） 數據庫命名

• 表——「模塊名_表名」。
• 字段——bool類型用「Is」、「Can」、「Has」等表示；日期類型命名必須包含「Date」；時間類型必須包含「Time」。
• 存儲過程——使用「proc_」前綴。
• 視圖——使用「view_」前綴。
• 觸發器——使用「trig_」前綴。

（八） XML命名

　　節點名稱使用Pascal風格，屬性名稱使用Camel風格。

四 註釋

• 對接口和複雜代碼塊必須進行註釋。
• 修改代碼時保持註釋同步。
• 未完成的功能使用TODO標記。
• 修改他人代碼時要先註釋對方代碼，並寫明修改緣由，不容許隨便刪除他人代碼。
• 發佈前移除無用註釋。

五 異常處理

• 原則上只容許顯示拋出InvalidOperationException、ArgumentException、ArgumentNullException和ArgumentOutOfRangeException四種異常類型。
• 在自定義異常時，必須使用VS提供的代碼模板來建立自定義異常。

 轉自：http://www.cnblogs.com/MeteorSeed/archive/2012/03/21/2404656.html