C#開發規範

1．定義
Pascal大寫—一種大小寫形式，所有單詞第一個字母大寫，其他字母小寫。
Camel大寫—一種大小寫形式，，除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。
2．規範
1. 類的命名規範
l         用名詞或名詞短語命名類。
l         使用Pascal大寫。
l         減少類名中縮寫的使用量。
l         不要使用任何類首碼。
l         不要使用帶底線的字元。下面是一些正確命名的類名的例子。
public class FileStream {
}
public class Button {
}
       2．介面的命名規範：
l         使用名詞或名詞短語，或者描述行為的形容詞來命名介面。例如，IComponent（描述性名詞），ICustomAttributeProvider（名詞短語），和IPersistable（形容詞）。
l         使用Pascal大寫。
l         減少介面名中縮寫的使用量。
l         不要使用帶底線的字元。
l         在介面名前加首碼I，以表示這個類型是一個介面。
l         不要在類名前加上首碼C。偶而情況下，需要在類名前加上I而並不表示它是一個介面。在這種情況下，只要I後面的字元是小寫就可（例如，IdentityStore。）
l         當類是介面的標準執行時，定義這一對類/介面組合就要使用相似的名稱。兩個名稱的不同之處只是介面名前有一個I首碼。下面我們舉個例子，來看看介面IComponent和它的標準執行，類Component。
public interface IComponent {
}

public class Component : IComponent{
}
public interface IServiceProvider{
}
public interface IFormatable {
}
3．方法命名規範：
l         用動詞或動詞短語命名方法。
l         用下述範例所示的Pascal大寫方式命名方法。
RemoveAll()
GetCharArray()
Invoke()
4．屬性命名規範：
l         用名詞或名詞短語命名屬性。
l         用Pascal大寫命名屬性。
l         屬性與類型要一樣。
 
5．變數命名規範：
l         變數和方法參數使用Camel 大小寫形式
public class HelloWorld{ int totalCount = 0; void SayHello(string name) { string fullMessage = "Hello " + name; ... }}l         不要使用匈牙利方法來命名變數。
以前，多數程式員喜歡它－把資料類型作為變數名的首碼而m_作為成員變數的首碼。例如：
string m_sName;int nAge;然而，這種方式在.NET編碼規範中是不推薦的。所有變數都用camel 大小寫形式，而不是用資料類型和m_來作首碼。
l         用有意義的，描述性的詞語來命名變數。
- 別用縮寫。用name, address, salary等代替 nam, addr, sal
- 別使用單個字母的變數象i, n, x 等. 使用 index, temp等
用於迴圈迭代的變數例外：
for ( int i = 0; i < count; i++ ){ ...}如果變數只用於迭代計數，沒有在迴圈的其他地方出現，許多人還是喜歡用單個字母的變數(i) ，而不是另外取名。
- 變數名中不使用底線 (_) 。
- 命名空間需按照標準的模式命名
6．檔案名稱要和類名匹配
例如，對於類HelloWorld, 相應的檔案名稱應為 helloworld.cs (或, helloworld.vb)
7．縮排和間隔
·  縮排用 TAB，不用 SPACES.。
·  注釋需和代碼對齊.。
·  花括弧 ( {} ) 需和括弧外的代碼對齊.。              
·  在一個類中，各個方法需用一空行，也只能是一行分開。
·  花括弧需獨立一行，而不象if, for 等可以跟括弧在同一行。.
好：
 if ( ... )   {   // Do something }不好：
 if ( ... ) {   // Do something }·  在每個運算子前後都空一格。.

好：
 if (showResult == true) {   for (int i = 0; i < 10; i++)   {    //   } }不好：
 if(showResult==true) {   for(int i= 0;i<10;i++)   {    //   } }8．良好的編程習慣
遵從以下良好的習慣以寫出好程式
·  避免使用大檔案。如果一個檔案裡的代碼超過300～400行，必須考慮將代碼分開到不同類中。
·  避免寫太長的方法。一個典型的方法代碼在1～25行之間。如果一個方法發代碼超過25行，應該考慮將其分解為不同的方法。
·  方法名需能看出它作什麼。別使用會引起誤解的名字。如果名字一目瞭然，就無需用文檔來解釋方法的功能了。

好：
 void SavePhoneNumber ( string phoneNumber ) { // Save the phone number. }
不好：
 // This method will save the phone number. void SaveData ( string phoneNumber ) { // Save the phone number. }·  一個方法只完成一個任務。不要把多個工作群組合到一個方法中，即使那些任務非常小。

好：
 // Save the address. SaveAddress ( address ); // Send an email to the supervisor to inform that the address is updated. SendEmail ( address, email );   void SaveAddress ( string address ) { // Save the address. // ... } void SendEmail ( string address, string email ) { // Send an email to inform the supervisor that the address is changed. // ... }
不好：
 // Save address and send an email to the supervisor to inform that the address is updated. SaveAddress ( address, email ); void SaveAddress ( string address, string email ) { // Job 1. // Save the address. // ... // Job 2. // Send an email to inform the supervisor that the address is changed. // ... }·  使用C# 或 VB.NET的特有類型，而不是System命名空間中定義的別名資料型別。

好：
 int age; string name; object contactInfo;
不好：
 Int16 age; String name; Object contactInfo;·  別在程式中使用固定數值，用常量代替。
·  別用字串常數，用資源檔。
·  避免使用很多成員變數。聲明局部變數，並傳遞給方法。不要在方法間共用成員變數。如果在幾個方法間共用一個成員變數，那就很難知道是哪個方法在什麼時候修改了它的值。
·  必要時使用enum，別用數字或字串來指示離散值。
好：
 enum MailType { Html, PlainText, Attachment } void SendMail (string message, MailType mailType) { switch ( mailType ) {   case MailType.Html:    // Do something    break;   case MailType.PlainText:    // Do something    break;   case MailType.Attachment:    // Do something    break;   default:    // Do something    break; } }           

不好：
 void SendMail (string message, string mailType) { switch ( mailType ) {   case "Html":    // Do something    break;   case "PlainText":    // Do something    break;   case "Attachment":    // Do something    break;   default:    // Do something    break; } }·  別把成員變數聲明為 public 或 protected。一般聲明為 private 而使用 public/protected 的Properties.
·  不在代碼中使用具體的路徑和磁碟機名。 使用相對路徑，並使路徑可程式化。
·  永遠別設想你的代碼是在“C:”盤運行。你不會知道，一些使用者在網路或“Z:”盤運行程式。
·  應用程式啟動時作些“自檢”並確保所需檔案和附件在指定的位置。必要時檢查資料庫連接。出現任何問題給使用者一個友好的提示。
·  如果需要的設定檔找不到，應用程式需能自己建立使用預設值的一份。
·  如果在設定檔中發現錯誤值，應用程式要拋出錯誤，給出提示訊息告訴使用者正確值。
·  錯誤訊息需能協助使用者解決問題。永遠別用象"應用程式出錯", "發現一個錯誤" 等錯誤訊息。而應給出象 "更新資料庫失敗。請確保登陸id和密碼正確。" 的具體訊息。  
·  顯示錯誤訊息時，除了說哪裡錯了，還應提示使用者如何解決問題。不要用 象 "更新資料庫失敗。"這樣的，要提示使用者怎麼做："更新資料庫失敗。請確保登陸id和密碼正確。
·  顯示給使用者的訊息要簡短而友好。但要把所有可能的資訊都記錄下來，以助診斷問題。
9．注釋
·  別每行代碼，每個聲明的變數都做注釋。
·  在需要的地方注釋。可讀性強的代碼需要很少的注釋。如果所有的變數和方法的命名都很有意義，會使代碼可讀性很強並無需太多注釋。
·  行數不多的注釋會使代碼看起來優雅。但如果代碼不清晰，可讀性差，那就糟糕。
·  如果應為某種原因使用了複雜艱澀的原理，為程式配備良好的文檔和重分的注釋。
10．異常處理
·  不要“捕捉了異常卻什麼也不做“。如果隱藏了一個異常，你將永遠不知道異常到底發生了沒有。
·  發生異常時，給出友好的訊息給使用者，但要精確記錄錯誤的所有可能細節，包括髮生的時間，和相關方法，類名等。
·  別寫太大的 try-catch 模組。如果需要，為每個執行的任務編寫單獨的 try-catch 模組。 這將幫你找出哪一段代碼產生異常，並給使用者發出特定的錯誤訊息
·  如果應用程式需要，可以編寫自己的異常類。自訂異常不應從基類SystemException派生，而要繼承於. IApplicationException。
好：
 void ReadFromFile ( string fileName ) {

 try {  

 // read from file.

} catch (FileIOException ex)

 {   // log error.   // re-throw exception depending on your case.   throw;

}

}不好：
 void ReadFromFile ( string fileName ) { try {   // read from file. } catch (Exception ex)   {   // Catching general exception is bad... we will never know whether it   // was a file error or some other error.      // Here you are hiding an exception.    // In this case no one will ever know that an exception happened.   return "";   } }