1、命名約定<?xml:namespace prefix = o />
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、文件頭部註釋
在代碼文件的頭部進行註釋,這樣做的好處在於,我們能對代碼文件做變更跟蹤。在代碼頭部分標註出創始人、創始時間、修改人、修改時間、代碼的功能,這在團隊開發中必不可少,它們可以使後來維護/修改的同伴在遇到問題時,在第一時間知道他應該向誰去尋求幫助,並且知道這個文件經歷了多少次迭代、經歷了多少個程序員的開發和修改。
樣本:
/********************************************************************************
** 作者: Eunge
** 創始時間:<?xml:namespace prefix = st1 />2004-6-8
** 修改人:Lucy
** 修改時間:2004-12-9
** 修改人:Lucy
** 修改時間:2005-01-29
** 描述:
** 主要用於產品信息的資料錄入,…
*********************************************************************************/
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裏面,有代碼佈局格式化功能,蠻有用的。其實代碼的規範是爲了使系統具有整體一致的編碼風格,以使後期維護人員能更快的讀懂代碼並進行維護。我認爲代碼規範有其必要性,但不能因爲規範而規範,從開發而言,開發是爲了更快的做出穩定的系統,而穩定的系統是爲了給公司帶來受益。開發人員、項目管理人員都應該更多的從項目經營的角度出來,同時站在公司、客戶的角度考慮問題,而不是因爲代碼而代碼。