C#程式設計命名規範

命名規範是一個十分重要但有比較有爭議的話題，本文主要談一下我的體會並介紹一種較常用的C#命名規範。

匈牙利命名法

我最早接觸到的命名規範是匈牙利命名法，該方法出自微軟，基本上是一些在你的所有變數前建立一個字首的規則。這個字首會說明那個變數的型別。其好處在於，通過它們的字首，你可以方便地知道兩個變數是否相容。這種方法非常流行，在目前的C和C++開發中還被廣泛的使用。

匈牙利命名法的不足

匈牙利命名法的最大的不足的地方就是繁瑣，隨著計算機的速度越來越快，IDE已擁有足夠的能力，可以開始實時探測變數的型別。因此，當你程式設計時，IDE能夠向你警告型別不相容的情況（通常普遍使用微軟Word自動拼寫檢查中的紅色彎曲下劃線）。

匈牙利命名法過分強調型別，在泛型方法中就顯得格格不入。另外，很多時候我們關心的只是這個變數所代表的意義而不是它的型別。像C++0x的auto關鍵字（雖然這個關鍵字在C++98中就存在，但沒法用）和C#的var關鍵字也說明了這一點。在小函式或者Lambda表示式這種比較簡單的流程的時候，過長的匈牙利變數顯得也很不合適。

其實主要的還是程式設計師懶惰心理作怪，但正是這種懶惰推動了計算機行業的不斷髮展。就連微軟也逐步減少了匈牙利命名法的使用，在其當家語言C#中主要使用的是帕斯卡命名法和駱駝命名法。下面就簡單的介紹一下常用的C#命名規範。

C#程式設計命名規範

   

具體如下：

1. 用camel規則來命名區域性變數和方法的引數,用pascal規則來命名方法和型別。
       publicclass TextBox
       {
           public void DataBind()
           {
           }
       }

   
   string userName;
   public AddUser(string userId,byte[] password);

2. 介面的名稱加字首 I.
   interfaceICompare
       {
           int Compare();
       }
3. 自定義的屬性以Attribute結尾
   publicclass AuthorAttribute :Attribute
   {
   }
4. 自定義的異常以Exception結尾
       publicclass AppException :Exception
       {
       }
5. 方法的命名。一般將其命名為動賓短語。
       ShowDialog()
       CreateFile()
       GetPath()
6. 程式碼的縮排。要用Tab，而不要用space.
7. 區域性變數的名稱要有意義。不要用x，y，z等等（除用於For迴圈變數中可使用i，j，k，l，m，n）。
8. 所有的成員變數宣告在類的頂端，用一個換行把它和方法分開。
9. 用有意義的名字命名namespace，如：產品名、公司名。
10. 生成和構建一個長的字串時，一定要使用StringBuilder，而不用string.
11. 始終使用"{ }"包含if下的語句，即使只有一條語句。
12. 把相似的內容放在一起，比如資料成員、屬性、方法、事件等，並適當的使用#region…#endregion，

需要記住的一點是：程式設計規範的目的是幫助程式設計師寫出簡潔規範易讀的程式，但也沒必要過分被其所約束。

 

 

(原文: http://www.cnblogs.com/TianFang/archive/2009/08/16/1547076.html)

 

 

* Another Good article On This Topic*

 

1、命名約定

Pascal和Camel命名約定

程式設計的命名方式主要有Pascal和Camel兩種（Pascal：每個單詞的首字母大寫，例如ProductType；Camel：首個單詞的首字母小寫，其餘單詞的首字母大寫，例如productType）

以下是一些常用的C#成員及其推薦命名方法： 

 

標誌符	規則	例項與描述
類class	Pascal	Application
列舉型別enum	Pascal	記住，是以Pascal命名，切勿包含Enum，否則FXCop會丟擲Issue
委託delegate	Pascal	以Pascal命名，不以任何特殊字串區別於類名、函式名
常量const	全部大寫	全部大寫，單詞間以下劃線隔開
介面interface	Pascal	IDisposable 注：總是以 I 字首開始，後接Pascal命名
方法function	Pascal	ToString
名稱空間namespace	Pascal	以.分隔，當每一個限定詞均為Pascal命名方式，比如： using ExcelQuicker.Framework
引數	Camel	首字母小寫
區域性變數	Camel	也可以加入型別識別符號，比如對於System.String型別，宣告變數是以str開頭，string strSQL = string.Empty;
資料成員	Camel	以m開頭＋Pascal命名規則，如mProductType（m意味member）
屬性	Pascal

 

 

1.1、區域性變數命名

在primitive的區域性變數命名時，使用Camel命名規則，

比如：int type = 0;

double count = 0;

…

對於string型別定義，通常使用str字首＋Pascal命名的方式，

比如string strSql = ""; //這是一種典型的命名SQL語句字串的方式。

而對於此外的型別物件定義，通常的做法是使用obj字首＋Pascal命名的方式，來告知我們這個變數是一個物件。或者也可以直接使用類名的Camel命名規則。

比如：Application objApplication = new Application();
            Application application = new Application();

 

1.2、引數命名

Camel命名規則，首字母小寫

 

1.3、類資料成員/屬性命名

資料成員命名以Camel命名方式，而屬性以Pascal命名。通常如果資料成員與屬性成對的話，資料成員與屬性的命名區別僅在於變數名的第一個字母是小寫還是大寫。

比如

class Appcalition

{

        private ArrayList worksheetCollection = new ArrayList();

        public ArrayList WorksheetCollection

        {

            get

            {

                return this.worksheetCollection;

            }

        }

}

另外，類的成員資料/方法呼叫時，應該加上this限定符，this在編輯環境中是藍色的，更利於我們區分區域性變數、引數或靜態變數，並且利於FXCop檢測區分。（如果使用FxCop掃描和檢測程式碼的話）

 

1.4、名稱空間命名

在dot之間的各限定字串符合Pascal格式

 

1.5、委託縮寫

委託的命名方式我常常以Pascal命名，並且在命名的後面加EventHandler

比如public delegate void MouseEventHandler (object sender, MouseEventArgs e);    //用於處理與滑鼠相關的事件或委託

對於自定義的委託，其引數第一個建議仍然使用object sender，sender代表觸發這個時間或委託的源物件。而第二個引數繼承於EventArgs類，並且在派生類中實現自己的業務邏輯。

 

1.6、自定義異常類

自定義異常類以Exception結尾，並且在類名中能清楚的描述出該異常的原因。比如NotFoundFileException，描述出了某個實體（檔案、記憶體區域等）無法被找到。

1.7、列舉

列舉的命名是Pascal命名，不需要在列舉中加入Enum，列舉的名稱能清楚的表明該列舉的用途。

 

1.8、常量命名

全部大寫，單詞間並且以下劃線間隔，如public const int LOCK_SECONDS = 3000;  雖然在MSDN中常量的命名推薦使用Pascal，但是從C++沿襲的命名規則來看，將常量全部大寫更加能清楚的表示常量與普通變數之間的區別。

 

1.9、命名縮寫

在一般情況下，不推薦縮寫命名，不要擔心變數命名長，長的變數名能使變數的意義更加清晰，其實從長變數名的負面作用三，因為Ctrl+C和Ctrl+V加上在VS中的智慧感知，其負面追用已經很小。變數命名的原則是，盡最大努力讓其他人在看到我們的變數/函式/…等的第一時間，大概能猜出它是做什麼的。

比如：int productTypeCount = 0; //我們在第一時間就能知道它是記錄產品的數量的變數

而對於糟糕的命名方式：int prodTypeCount = 0; //它是productTypeCount的簡寫，我們一部分人也許知道prod是product的縮寫，但是每人能保證所有的人都知道它。我個人認為：最優秀的程式碼它本身就是註釋。作為一流的程式設計師。並不僅僅實現功能，而是要讓我們的程式碼更加優美，具備讓他人維護或今後擴充的能力。作為現在的業務系統，其門檻的准入水平已大大降低，實現功能上的需求已沒有什麼難度，但是高手和菜鳥的區別在於，高手的程式碼通俗易懂，在整個編碼的過程中，不僅能考慮到效能、還會考慮程式碼可讀性和維護性。

1.10、資料庫命名

資料庫的欄位、表名的命名都推薦採用Pascal命名方式，儘量不採用縮寫。當然，使用長的欄位名、表名，可能會使SQL語句的編寫帶來負面影響。我推薦大家可以使用一些ORM，ORM的效能肯定不會比直接寫SQL的好，但是如果做業務系統，更重要的是系統多久能交付使用者使用，ORM不僅使開發時間可以縮短不少，並且在後期的維護上也比直接寫SQL便利很多。

2、註釋規範

2.1、檔案頭部註釋

在程式碼檔案的頭部進行註釋，這樣做的好處在於，我們能對程式碼檔案做變更跟蹤。在程式碼頭部分標註出創始人、創始時間、修改人、修改時間、程式碼的功能，這在團隊開發中必不可少，它們可以使後來維護/修改的同伴在遇到問題時，在第一時間知道他應該向誰去尋求幫助，並且知道這個檔案經歷了多少次迭代、經歷了多少個程式設計師的開發和修改。

樣本：

 

 

2.2、函式、屬性、類等註釋

請使用///三斜線註釋，這種註釋是基於XML的，不僅能匯出XML製作幫助文件，而且在各個函式、屬性、類等的使用中，編輯環境會自動帶出註釋，方便你的開發。以protected，protected Internal，public宣告的定義註釋都建議以這樣命名方法。

例如：

/// <summary>

/// 用於從ERP系統中撈出產品資訊的類

/// </summary>

class ProductTypeCollector

{

       …

}

 

2.3、邏輯點註釋

在我們認為邏輯性較強的地方加入註釋，說明這段程式的邏輯是怎樣的，以方便我們自己後來的理解以及其他人的理解，並且這樣還可以在一定程度上排除BUG。在註釋中寫明我們的邏輯思想，對照程式，判斷程式是否符合我們的初衷，如果不是，則我們應該仔細思考耀修改的是註釋還是程式了…

 

3、排版

我的排版原則與建議：

1、  每行語句至少佔一行，如果語句過長（超過一屏），則該語句斷為兩行顯示；

2、  把相似的內容放在一起，比如資料成員、屬性、方法、事件等，並適當的使用#region…#endregion，我最喜歡把機器生成的程式碼都放在一個#region裡面，比如在編寫ASP.NET程式時，對應自動產生的控制元件定義，我常用#region Automatic Generated Web Components … #endregion把他們框住

3、  使用空格，

（1）       雙目操作符的前後加空格(+, =, && 等)，index = index + 1;

（2）       單目操作符前加空格(!, ++, ~ 等)， index ++;

（3）       逗號、分號只在後面加空格

4、  使用空行，在一段功能程式碼、或者函式、屬性之間插入空行，這樣會很直觀。

在Visual Studio 2005中，其實已經帶有程式碼格式化這樣的功能，快捷鍵是Ctrl+K -> Ctrl+D。
 

4、介面控制元件命名

我的建議是使用預設控制元件名作為字首，字首名稱全部小寫，這樣的好處是不必為未知的控制元件統一命名方式發愁，比如對於Label標籤控制元件，有的人用縮寫lbl，有的人用lab，有的人用lb。這樣其實仍然是避免使用縮寫，有的時候仍然會使命名變得冗長，但是命名更加能反應出變數的意義，並且各個開發人員也能更好的執行，因為他們不需要去背記各個變數的縮寫。

protected System.Web.UI.WebControls.Button buttonQuery;

protected System.Web.UI.WebControls.DropDownList dropdownlistProductType;

protected System.Web.UI.WebControls.TextBox textboxManufactureDate;

 

5、程式碼可讀性一些建議

（1）注意運算子的優先順序，我們應該儘量使用括號明確表示式的操作順序，避免使用預設優先順序，給我們以及維護人帶來困擾

（2）避免使用不易理解的數字，用有意義的標識來替代（列舉和常量）

比如：

 

if(productType == 0)        … else if (productType == 1)        … （不推薦使用）

if(productType == ProductType.CD)        … else if (productType == ProductType.DVD)        … （推薦使用）

 

 

（3）在介面層中儘量使用異常處理try語句，不要將系統級別的錯誤直接暴露給使用者，而更應該的是把系統丟擲的錯誤資訊記錄到LOG日誌檔案中去，告訴使用者友好的提示資訊

在Visual Studio 2005裡面，有程式碼佈局格式化功能，蠻有用的。其實程式碼的規範是為了使系統具有整體一致的編碼風格，以使後期維護人員能更快的讀懂程式碼並進行維護。我認為程式碼規範有其必要性，但不能因為規範而規範，從開發而言，開發是為了更快的做出穩定的系統，而穩定的系統是為了給公司帶來受益。開發人員、專案管理人員都應該更多的從專案經營的角度出來，同時站在公司、客戶的角度考慮問題，而不是因為程式碼而程式碼。