C#編碼規範

C#編碼規範

1. 避免將多個類放在一個檔案裡面。

2. 一個檔案應該只有一個命名空間，避免將多個命名空間放在同一個檔案裡面。

3. 一個檔案最好不要超過500行的代碼（不包括IDE產生的代碼）。

4. 一個方法的代碼長度最好不要超過25行。

5. 避免方法中有超過5個參數的情況。如果超過了，則應使用 struct 來傳遞多個參數。

6. 每行代碼不要超過80個字元。

7. 原則上，盡量不要手工的修改機器產生的代碼。

a) 如果需要編輯機器（IDE）產生的代碼，編輯格式和風格要符合該編碼通訊協定。

b) 儘可能地使用片斷類來把被保持的部分分解為各個因素

    註：這裡的翻譯參考了靈感之源老兄的說法，在Visual c#2005中，C#的文法已經支援partial修飾符，它的作用是可以將一個完整的類分解各個部分類，在編譯時間，編譯器會將它們構造為一個類。

具體請參考

http://weblogs.asp.net/jaybaz_ms/archive/2004/04/28/122392.aspx

8. 避免利用注釋解釋顯而易見的代碼。

a) 代碼應該可以自解釋。好的代碼本身就應具體良好的可讀性，所使用的變數和方法命名一般情況下不需要注釋。

9. 文檔應該僅用於assumptions, algorithm insights等等.

10. 避免使用方法級的文檔。

a) 使用擴充的API文檔進行說明。

b) 只有在該方法需要被其他的開發人員使用的時候才使用方法級的注釋。（在C#中就是///）

11. 不要寫入程式碼數位值，總是使用建構函式設定其值。

12. 只有是自然結構才能直接使用const(常量)，比如一個星期的天數。

13. 區別唯讀變數及常量的使用方法，如果想實現唯讀變數，可以直接使用readonly 修飾符。

public class MyClass

{

   public readonly int Number;

   public MyClass(int someValue)

   {

      Number = someValue;

   }

   public const int DaysInWeek = 7;

}

14. 每個假設必須使用Assert檢查

a) 平均每15行要有一次檢查(Assert)

using System.Diagnostics;

    object GetObject()

{…}

    object obj = GetObject();

Debug.Assert(obj != null);

15. 代碼的每一行都應該通過白盒方式的測試。

16. 只拋出已經顯示處理的異常。

17. 在捕獲(catch)語句的拋出異常子句中(throw)，總是拋出原始異常，用以維護原始錯誤的堆棧分配。
　　catch(Exception exception)

{   

     MessageBox.Show(exception.Message);

      throw ; //和throw exception一樣。

}

　　註：同理，不推薦在迴圈語句中，進行直接的return操作。
    for (int i=0;i<100;i++)
    {
        if (i==10)
        {
            return; //不推薦的方式
        }
    }

18. 避免方法的傳回值是錯誤碼。

19. 盡量避免定義自訂異常類。

20. 當需要定義自訂的異常時：

a) 自訂異常要繼承於ApplicationException。

b) 提供自訂的序列化功能。

21. 避免在單個程式集裡使用多個Main方法。

22. 只對外公布必要的操作，其他的則為internal。

23. 避免使用friend 組件，因為它會增加程式集間的耦合度。

24. 避免編寫從指定的位置載入的程式集的代碼。

25. 使應用程式集盡量為最小化代碼(EXE客戶程式)。使用類庫來替換包含的商務邏輯。

26. 避免給枚舉變數提供顯式的值。

//正確方法 

public enum Color

{   

   Red,Green,Blue

}

//避免

public enum Color

{   

   Red = 1,Green = 2,Blue = 3

}

27. 避免指定特殊類型的枚舉變數。

//避免 

public enum Color : long

{   

   Red,Green,Blue

}

28. 即使if語句只有一句，也要將if語句的內容用大括弧擴起來。

29. 避免使用trinary條件操作符。

30. 避免在條件陳述式中調用返回bool值的函數。可以使用局部變數並檢查這些局部變數。

bool IsEverythingOK()

{…}

//避免

if (IsEverythingOK ())

{…}

//替換方案 

bool ok = IsEverythingOK();

if (ok)

{…}

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

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

public class MyClass

{}

MyClass[] array = new MyClass[100];

for(int index = 0; index < array.Length; index++)

{

   array[index] = new MyClass();

}

33.  盡量不要提供public 和 protected的成員變數，使用屬性代替他們。

34. 避免在繼承中使用new而使用override來進行替換。

35. 在不是sealed的類中總是將public 和 protected的方法標記成virtual的。

36. 除非使用interop(COM+ 或其他的dll)代碼否則不要使用不安全的代碼(unsafe code)。

37. 避免顯式的轉換，使用as操作符進行相容類型的轉換。

Dog dog = new GermanShepherd();

GermanShepherd shepherd = dog as GermanShepherd;

if (shepherd != null )

{…}

38. 當類成員包括委託的時候

a)  在調用委託前，將它拷貝到一個本地變數中，用以避免並發競爭條件。

b) 在調用委託之前一定要檢查它是否為null

public class MySource

{

   public event EventHandler MyEvent;

   public void FireEvent()

   { 
　　　//將委託拷到一個本地變數中。
      EventHandler temp = MyEvent;

      //確定它是否為空白 
      if(temp != null )

      {

         temp(this,EventArgs.Empty);

      }

   }

}  

39. 不要提供公用的事件成員變數，使用事件訪問器替換這些變數。

public class MySource

{

   MyDelegate m_SomeEvent ;

   public event MyDelegate SomeEvent

   {

      add

      {

         m_SomeEvent += value;

      }

      remove

      {

         m_SomeEvent -= value;

      }

   }

}

40. 使用一個事件協助類來公布事件的定義。

41. 總是使用介面。

42. 類和介面中的方法和屬性至少為2:1的比例。

43. 避免一個介面中只有一個成員。

44. 盡量使每個介面中包含3－5個成員。

45. 介面中的成員不應該超過20個。

a) 根據實際情況可能限制為12個

46. 避免介面成員中包含事件。

47. 避免使用抽象方法而使用介面替換。

48. 在類層次中顯示介面。

49. 推薦使用顯式的介面實現。

50. 從不假設一個類型相容一個介面，並應防止查詢那些介面。

SomeType obj1;

IMyInterface obj2;

 

/* 假設已有代碼初始化過obj1，接下來 */

obj2 = obj1 as IMyInterface;

if (obj2 != null)

{

   obj2.Method1();

}

else

{

   //處理錯誤

}  

51. 表現給終端使用者的字串（一般指UI介面中的部分）不要使用直接編碼，而應該要使用資源檔來替換。

          註：這樣做的目的是方便軟體的本地化。

52. 不要直接編寫可能會更改的基於配置的字串，比如連接字串。

53. 當需要構建較長的字串的時候，應該考慮使用StringBuilder不要使用string來處理。

註：string每次要建立一個新的執行個體，較佔用空間，併產生了相對StringBuilder更大的效能消耗。對於過於頻繁的字串操作，採用StringBuilder是一個良好的習慣。

54. 避免在結構裡面提供方法。

a) 建議使用參數化建構函式

b) 可以重載操作符

55. 總是要給靜態變數提供靜態建構函式。

56. 在能夠使用早期繫結的情況下，盡量避免使用後期綁定。

　　 註：後期綁定雖然靈活，但帶來的不僅僅是效能上的消耗，更多的是編碼上的複雜性和混亂的邏輯。

57. 使用應用程式的日誌和跟蹤。

58. 除非在不完全的switch語句中否則不要使用goto語句。

     註：原則上不應使用goto語句，除非在能夠大大減輕編碼的複雜性，並不影響可讀性的前提下才允許使用。

59. 在switch語句中總是要有default子句來顯示資訊(Assert)。

int number = SomeMethod();

switch(number)

{

   case 1:

      Trace.WriteLine("Case 1:");

      break;

   case 2:

      Trace.WriteLine("Case 2:");

      break;

   default :

      Debug.Assert(false);

      break;

}

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

// 正確使用this的例子

public class MyClass

{

   public MyClass(string message )

   {}

   public MyClass() : this("hello")

   {}

}

61. 除非你想重寫子類中存在名稱衝突的成員或者調用基類的建構函式否則不要使用base來訪問基類的成員。

// 正確使用base的例子

public class Dog

{

   public Dog(string name)

   {}

   virtual public void Bark( int howLong)

   {}

}

public class GermanShepherd : Dog

{

   public GermanShe pherd(string name): base (name)

   {}

   override public void Bark(int howLong) 

   {

      base .Bark(howLong);  

   }

}

62. 基於模板的時候要實現Dispose()和Finalize()兩個方法。

63. 通常情況下避免有從System.Object轉換來和由System.Object轉換去的代碼，而使用強制轉換或者as操作符替換。

class SomeClass

{}

//避免：

class MyClass<T> 

{   

   void SomeMethod(T t)   

   {

      object temp = t;      

      SomeClass obj = (SomeClass)temp;    

   }

}

// 正確：

class MyClass<T> where T : SomeClass

{   

   void SomeMethod(T t)   

   {

      SomeClass obj = t;   

   }

}

64. 在一般情況下不要定義有限制符的介面。介面的限制層級通常可以用強型別來替換之。

public class Customer

{…}

//避免：

public interface IList<T> where T : Customer 

{…}

//正確：

public interface ICustomerList : IList<Customer> 

{…}

65. 不確定在介面內的具體方法的限制條件。

66. 總是選擇使用C#內建（一般的generics）的資料結構

67、初始化類的執行個體時，除非十分必要，否則不要賦null值。
68、使用後的執行個體，盡量不要將該執行個體的引用賦值和為nul，尤其是採用public來修飾的類成員l。
1）　如果該執行個體是臨時引用，請使用using語句，然後在程式塊中使用。
2）　如果需要釋放資源，應可能地使用Dispose，採用null值的方法，該引用在指向下一個執行個體前，不會被回收。