C# 編碼規範

標籤：style   blog   使用   os   io   檔案   資料   for   

C# 編碼規範  

 

由於在做OA項目的後期，需要對整體的代碼進行一些最佳化，整理和總結了一些經驗和編碼規範，分享一下，希望對您有用。

編程高手與初級編程人員的最根本區別就在於他們時時刻刻在考慮效率問題，因為這個時代是一個效率至上的時代，如果效率跟不上，那麼您就會被您的競爭 對手牢牢的甩在身後，可能您又會問，如何提高效率了，也就是具體的方案，其實很簡單，從沒一點做起，有這樣一個等式六個百分之九十九十百分之五十九，九十 不及格。所以效率是從每一個人，每一行代碼，每一個流程邏輯入手的，下面詳細羅列了七十九條編碼規範：

 

1. 避免將多個類放在一個檔案裡面，至於每個檔案放多少個類，視具體情況而定。 
2. 一個檔案應該只有一個命名空間，避免將多個命名空間放在同一個檔案裡面。 
3. 一個檔案最好不要超過500行的代碼(不包括機器產生的代碼）。 
4. 一個方法的代碼長度最好不要超過25行。 
5. 避免方法中有超過5個參數的情況。使用結構來傳遞多個參數（類和結構的不同前面已經敘述過）
6. 每行代碼不要超過80個字元。 
7. 不要手工的修改機器產生的代碼。 
如果需要編輯機器產生的代碼，編輯格式和風格要符合該編碼通訊協定。 
8. 避免利用注釋解釋顯而易見的代碼。 
a) 代碼應該可以自解釋。好的代碼由可讀的變數和方法命名因此不需要注釋。 
10. 避免使用方法級的文檔。 
a) 使用擴充的API文檔說明。 
b) 只有在該方法需要被其他的開發人員使用的時候才使用方法級的注釋。（在C#中就是///） 
11. 不要寫入程式碼數位值，總是使用建構函式設定其值。 
12. 只有是自然結構才能直接使用const。 
13. 避免在唯讀變數上使用const。如果想實現唯讀，可以直接使用readonly。 
14. 每個假設必須使用Assert檢查 
a) 平均每15行要有一次檢查(Assert) 
15. 代碼的每一行都應該通過白盒方式的測試。 
16. 只拋出已經顯示處理的異常。 
17. 在捕獲(catch)語句的拋出異常子句中(throw)，總是拋出原始異常維護原始錯誤的堆棧分配（注意系統處理拋出異常是很耗費資源的）。 
18. 避免方法的傳回值是錯誤碼。 
19. 盡量避免定義自訂異常類。 
20. 當需要定義自訂的異常時： 
a) 自訂異常要繼承於ApplicationException。 
b) 提供自訂的序列化功能。 
21. 避免在單個程式集裡使用多個Main方法。 
22. 只對外公布必要的操作，其他的則為internal。 
25. 使應用程式集盡量為最小化代碼(EXE客戶程式)。使用類庫來替換包含的商務邏輯。 
26. 避免給枚舉變數提供顯式的值。 
27. 避免指定特殊類型的枚舉變數。 
28. 即使if語句只有一句，也要將if語句的內容用大括弧擴起來。  
29. 避免在條件陳述式中調用返回bool值的函數。可以使用局部變 量並檢查這些局部變數。

30. 總是使用基於0開始的數組。

31. 在迴圈中總是顯式的初始化參考型別的數組。

32. 在迴圈中總是顯式的初始化參考型別的數組。 
33. 不要提供public 和 protected的成員變數，使用屬性代替他們。 
34. 避免在繼承中使用new而使用override替換。 
35. 在不是sealed的類中總是將public 和 protected的方法標記成virtual的。 
36. 除非使用interop(COM+ 或其他的dll)代碼否則不要使用不安全的代碼(unsafe code)。 
37. 避免顯示的轉換，使用as操作符進行相容類型的轉換。 
38. 當類成員包括委託的時候 
b) 在調用委託之前一定要檢查它是否為null 
39. 不要提供公用的事件成員變數，使用事件訪問器替換這些變數。 
40. 使用一個事件協助類來公布事件的定義。 
41. 總是使用介面。 
42. 類和介面中的方法和屬性至少為2:1的比例。 
43. 避免一個介面中只有一個成員。 
44. 盡量使每個介面中包含3－5個成員。 
45. 介面中的成員不應該超過20個。 
a) 實際情況可能限制為12個 
46. 避免介面成員中包含事件。 
47. 避免使用抽象方法而使用介面替換。 
48. 在類層次中顯示介面。 
49. 推薦使用顯式的介面實現。 
50. 從不假設一個類型相容一個介面。
51. 表現給終端使用者的字串不要使用寫入程式碼而要使用資源檔替換之。 
52. 不要寫入程式碼可能更改的基於配置的字串，比如連接字串。 
53. 當需要構建長的字串的時候，使用StringBuilder不要使用string 
54. 避免在結構裡面提供方法。 
a) 建議使用參數化建構函式 
b) 可以重裁操作符 
55. 總是要給靜態變數提供靜態建構函式。 
56. 能使用早期繫結就不要使用後期綁定。 
57. 使用應用程式的日誌和跟蹤。 
58. 除非在不完全的switch語句中否則不要使用goto語句。 
59. 在switch語句中總是要有default子句來顯示資訊(Assert)。

60. 除非在建構函式中調用其他建構函式否則不要使用this指標。

60. 除非在建構函式中調用其他建構函式否則不要使用this指標。 
61. 除非你想重寫子類中存在名稱衝突的成員或者調用基類的建構函式否則不要使用base來訪問基類的成員。 
62. 基於模板的時候要實現Dispose()和Finalize()兩個方法。 
63. 通常情況下避免有從System.Object轉換來和由System.Object轉換去的代碼，而使用強制轉換或者as操作符替換。
64. 在一般情況下不要定影有限制符的介面。介面的限制層級通常可以用強型別來替換之
65. 不確定在介面內的具體方法的限制條件。 
66. 總是選擇使用C#內建（一般的generics）的資料結構。 

67.Foreach比for語句具有更高效的執行效率,for寫入時間大約是讀取時間的10倍.

68.避免使用ArrayList,因為任何放入ArrayList中的對象均要進行裝箱為object 對象。

69.實用Hashtable代替其他字典，存放少量資料時使用。

70.將固定字串放在常量中定義。

71.不實用UpperCase和LowerCase進行字串的比較，而改用Compare（）。

72.用StringBuilder來代替字串的串連+操作符。

73.如果對於XML檔案只涉及到讀取，使用XPathDocument代替XDocument對象。

74.避免在迴圈中建立對象。

75.捕獲指定異常，不要只使用通用的Exception對象。

76.不要使用Exception來控製程序流程。

77.使用using和Try/Catch來進行資源清理。

78.避免使用反射，反射會降低系統效能。在使用反射時，會進行校正參數，檢查許可權，可以使用動態構建類型來應用。

79.使用實值型別的Tostring（）來避免裝箱操作。

其實如果您經常使用IL進行反組譯碼來查看您寫的代碼的話，那麼您就會發現，上面的這些規則其實就是微軟在開發C#語言所做的一些內部規定最佳化。做不 了遊戲規則的制定者，就好好遵守遊戲規則吧！