C#開發編碼規範

C#開發編碼規範

註記：

Pascal 大小寫形式——所有單詞第一個字母大寫，其他字母小寫。
Camel 大小寫形式——除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。
類名使用Pascal大小寫形式
public class HelloWorld
{
…
}
方法使用Pascal大小寫形式
public class HelloWorld
{
void SayHello(string name)
{
…
}
}
變數和方法參數使用Camel 大小寫形式
public class HelloWorld
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
…
}
}
  不要使用匈牙利方法來命名變數。
以前，多數程式員喜歡把資料類型作為變數名的首碼而m_作為成員變數的首碼。例如：
string m_sName;
int nAge;
然而，這種方式在.NET編碼規範中是不推薦的。所有變數都用Camel 大小寫形式，而不是用資料類型和m_來作首碼。用有意義的，描述性的詞語來命名變數。別用縮寫。用name，address，salary等代替nam，addr，sal。別使用單個字母的變數象i，n，x 等。使用 index，temp等。用於迴圈迭代的變數例外：
for ( int i = 0; i < count; i++ )
{
…
}
如果變數只用於迭代計數，沒有在迴圈的其他地方出現，許多人還是喜歡用單個字母的變數(i) ，而不是另外取名。變數名中不使用底線 (_) 。命名空間需按照標準的模式命名。檔案名稱要和類名匹配，例如，對於類HelloWorld，相應的檔案名稱應為helloworld.cs (或，helloworld.vb)

縮排和間隔

縮排用TAB。不用 SPACES。注釋需和代碼對齊。花括弧 ( {} ) 需和括弧外的代碼對齊。用一個空行來分開代碼的邏輯分組。
bool SayHello (string name)
{
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;
string message = fullMessage + ",the time is : " + currentTime.ToShortTimeString();
MessageBox.Show ( message );
if ( … )
{
  // Do something
  // …
  return false;
}
return true;
}
       
這段代碼看起來比上面的好：
bool SayHello ( string name )
{
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;
  string message = fullMessage + ",the time is : " + currentTime.ToShortTimeString();
  MessageBox.Show ( message );
  if ( … )
{
  // Do something
  // …
    return false;
}
  return true;
}
在一個類中，各個方法需用一空行，也只能是一行分開。花括弧需獨立一行，而不象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++)
  {
  //
  }
}

良好的編程習慣

遵從以下良好的習慣以寫出好程式。
避免使用大檔案。如果一個檔案裡的代碼超過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和密碼正確。”
顯示給使用者的訊息要簡短而友好。但要把所有可能的資訊都記錄下來，以助診斷問題。

注釋

別每行代碼，每個聲明的變數都做注釋。在需要的地方注釋。可讀性強的代碼需要很少的注釋，如果所有的變數和方法的命名都很有意義，會使代碼可讀性很強並無需太多注釋。行數不多的注釋會使代碼看起來優雅。但如果代碼不清晰，可讀性差，那就糟糕。如果因為某種原因使用了複雜艱澀的原理，為程式配備良好的文檔和重分的注釋。對一個數值變數採用不是0，-1等的數值初始化，給出選擇該值的理由。簡言之，要寫清晰，可讀的代碼以致無須什麼注釋就能理解。對注釋做拼字檢查，保證文法和標點符號的正確使用。

異常處理

不要“捕捉了異常卻什麼也不做”。如果隱藏了一個異常，你將永遠不知道異常到底發生了沒有。發生異常時，給出友好的訊息給使用者，但要精確記錄錯誤的所有可能細節，包括髮生的時間，和相關方法，類名等。只捕捉特定的異常，而不是一般的異常。
好：
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 "";
}
}
不必在所有方法中捕捉一般異常。不管它，讓程式崩潰。這將協助你在開發週期發現大多數的錯誤。你可以用應用程式級（線程級）錯誤處理器處理所有一般的異常。遇到“意外的一般性錯誤”時，此錯誤處理器應該捕捉異常，給使用者提示訊息，在應用程式關閉或使用者選擇“忽略並繼續”之前記錄錯誤資訊。不必每個方法都用try-catch。當特定的異常可能發生時才使用。比如，當你寫檔案時，處理異常FileIOException。別寫太大的 try-catch 模組。如果需要，為每個執行的任務編寫單獨的 try-catch 模組。這將幫你找出哪一段代碼產生異常，並給使用者發出特定的錯誤訊息如果應用程式需要，可以編寫自己的異常類。自訂異常不應從基類SystemException派生，而要繼承於IApplicationException。