詳解C#命名規(guī)約
C#命名規(guī)約顧名思義就是對(duì)C#類和命名空間的命名進(jìn)行規(guī)范,這樣能讓名字更加規(guī)范和標(biāo)準(zhǔn)化,有利于今后的維護(hù)工作。
1、C#命名規(guī)約
Pascal和Camel命名約定
編程的命名方式主要有Pascal和Camel兩種(Pascal:每個(gè)單詞的首字母大寫(xiě),例如ProductType;Camel:首個(gè)單詞的首字母小寫(xiě),其余單詞的首字母大寫(xiě),例如productType)
以下是一些常用的C#成員及其推薦命名方法:
標(biāo)志符
規(guī)則
實(shí)例與描述
類class
Pascal
Application
枚舉類型enum
Pascal
記住,是以Pascal命名,切勿包含Enum,否則FXCop會(huì)拋出Issue
委托delegate
Pascal
以Pascal命名,不以任何特殊字符串區(qū)別于類名、函數(shù)名
常量const
全部大寫(xiě)
全部大寫(xiě),單詞間以下劃線隔開(kāi)
接口interface
Pascal
IDisposable 注:總是以 I 前綴開(kāi)始,后接Pascal命名
方法function
Pascal
ToString
命名空間namespace
Pascal
以.分隔,當(dāng)每一個(gè)限定詞均為Pascal命名方式,比如:
using ExcelQuicker.Framework
參數(shù)
Camel
首字母小寫(xiě)
局部變量
Camel
也可以加入類型標(biāo)識(shí)符,比如對(duì)于System.String類型,聲明變量是以str開(kāi)頭,string strSQL = string.Empty;
數(shù)據(jù)成員
Camel
以m開(kāi)頭+Pascal命名規(guī)則,如mProductType(m意味member)
屬性
Pascal
1.1、局部變量命名在primitive的局部變量命名時(shí),使用Camel命名規(guī)則,
比如:int type = 0;
double count = 0;
…
對(duì)于string類型定義,通常使用str前綴+Pascal命名的方式,
比如string strSql = ""; //這是一種典型的命名SQL語(yǔ)句字符串的方式。
而對(duì)于此外的類型對(duì)象定義,通常的做法是使用obj前綴+Pascal命名的方式,來(lái)告知我們這個(gè)變量是一個(gè)對(duì)象。或者也可以直接使用類名的Camel命名規(guī)則。
比如:Application objApplication = new Application();
Application application = new Application();
1.2、參數(shù)命名Camel命名規(guī)則,首字母小寫(xiě)
1.3、類數(shù)據(jù)成員/屬性命名數(shù)據(jù)成員命名以Camel命名方式,而屬性以Pascal命名。通常如果數(shù)據(jù)成員與屬性成對(duì)的話,數(shù)據(jù)成員與屬性的命名區(qū)別僅在于變量名的第一個(gè)字母是小寫(xiě)還是大寫(xiě)。
比如
- class Appcalition
- {
- private ArrayList worksheetCollection = new ArrayList();
- public ArrayList WorksheetCollection
- {
- get
- {
- return this.worksheetCollection;
- }
- }
- }
另外,類的成員數(shù)據(jù)/方法調(diào)用時(shí),應(yīng)該加上this限定符,this在編輯環(huán)境中是藍(lán)色的,更利于我們區(qū)分局部變量、參數(shù)或靜態(tài)變量,并且利于FXCop檢測(cè)區(qū)分。(如果使用FxCop掃描和檢測(cè)代碼的話)
1.4、命名空間命名在dot之間的各限定字符串符合Pascal格式
1.5、委托縮寫(xiě)委托的命名方式我常常以Pascal命名,并且在命名的后面加EventHandler
比如public delegate void MouseEventHandler (object sender, MouseEventArgs e); //用于處理與鼠標(biāo)相關(guān)的事件或委托
對(duì)于自定義的委托,其參數(shù)第一個(gè)建議仍然使用object sender,sender代表觸發(fā)這個(gè)時(shí)間或委托的源對(duì)象。而第二個(gè)參數(shù)繼承于EventArgs類,并且在派生類中實(shí)現(xiàn)自己的業(yè)務(wù)邏輯。
1.6、自定義異常類自定義異常類以Exception結(jié)尾,并且在類名中能清楚的描述出該異常的原因。比如NotFoundFileException,描述出了某個(gè)實(shí)體(文件、內(nèi)存區(qū)域等)無(wú)法被找到。
1.7、枚舉枚舉的命名是Pascal命名,不需要在枚舉中加入Enum,枚舉的名稱能清楚的表明該枚舉的用途。
1.8、常量命名全部大寫(xiě),單詞間并且以下劃線間隔,如public const int LOCK_SECONDS = 3000; 雖然在MSDN中常量的命名推薦使用Pascal,但是從C++沿襲的命名規(guī)則來(lái)看,將常量全部大寫(xiě)更加能清楚的表示常量與普通變量之間的區(qū)別。
1.9、命名縮寫(xiě)在一般情況下,不推薦縮寫(xiě)命名,不要擔(dān)心變量命名長(zhǎng),長(zhǎng)的變量名能使變量的意義更加清晰,其實(shí)從長(zhǎng)變量名的負(fù)面作用三,因?yàn)镃trl+C和Ctrl+V加上在VS中的智能感知,其負(fù)面追用已經(jīng)很小。變量命名的原則是,盡最大努力讓其他人在看到我們的變量/函數(shù)/…等的第一時(shí)間,大概能猜出它是做什么的。
比如:int productTypeCount = 0; //我們?cè)诘谝粫r(shí)間就能知道它是記錄產(chǎn)品的數(shù)量的變量
而對(duì)于糟糕的命名方式:int prodTypeCount = 0; //它是productTypeCount的簡(jiǎn)寫(xiě),我們一部分人也許知道prod是product的縮寫(xiě),但是每人能保證所有的人都知道它。我個(gè)人認(rèn)為:最優(yōu)秀的代碼它本身就是注釋。作為一流的程序員。并不僅僅實(shí)現(xiàn)功能,而是要讓我們的代碼更加優(yōu)美,具備讓他人維護(hù)或今后擴(kuò)充的能力。作為現(xiàn)在的業(yè)務(wù)系統(tǒng),其門(mén)檻的準(zhǔn)入水平已大大降低,實(shí)現(xiàn)功能上的需求已沒(méi)有什么難度,但是高手和菜鳥(niǎo)的區(qū)別在于,高手的代碼通俗易懂,在整個(gè)編碼的過(guò)程中,不僅能考慮到性能、還會(huì)考慮代碼可讀性和維護(hù)性。
1.10、數(shù)據(jù)庫(kù)命名數(shù)據(jù)庫(kù)的字段、表名的命名都推薦采用Pascal命名方式,盡量不采用縮寫(xiě)。當(dāng)然,使用長(zhǎng)的字段名、表名,可能會(huì)使SQL語(yǔ)句的編寫(xiě)帶來(lái)負(fù)面影響。我推薦大家可以使用一些ORM,ORM的性能肯定不會(huì)比直接寫(xiě)SQL的好,但是如果做業(yè)務(wù)系統(tǒng),更重要的是系統(tǒng)多久能交付用戶使用,ORM不僅使開(kāi)發(fā)時(shí)間可以縮短不少,并且在后期的維護(hù)上也比直接寫(xiě)SQL便利很多。
2、注釋規(guī)范
2.1、文件頭部注釋在代碼文件的頭部進(jìn)行注釋,這樣做的好處在于,我們能對(duì)代碼文件做變更跟蹤。在代碼頭部分標(biāo)注出創(chuàng)始人、創(chuàng)始時(shí)間、修改人、修改時(shí)間、代碼的功能,這在團(tuán)隊(duì)開(kāi)發(fā)中必不可少,它們可以使后來(lái)維護(hù)/修改的同伴在遇到問(wèn)題時(shí),在第一時(shí)間知道他應(yīng)該向誰(shuí)去尋求幫助,并且知道這個(gè)文件經(jīng)歷了多少次迭代、經(jīng)歷了多少個(gè)程序員的開(kāi)發(fā)和修改。
樣本:
/********************************************************************************
** 作者: Eunge
** 創(chuàng)始時(shí)間: 2004-6-8
** 修改人:Lucy
** 修改時(shí)間:2004-12-9
** 修改人:Lucy
** 修改時(shí)間:2005-01-29
** 描述:
** 主要用于產(chǎn)品信息的資料錄入,…
*********************************************************************************/
2.2、函數(shù)、屬性、類等注釋請(qǐng)使用///三斜線注釋,這種注釋是基于XML的,不僅能導(dǎo)出XML制作幫助文檔,而且在各個(gè)函數(shù)、屬性、類等的使用中,編輯環(huán)境會(huì)自動(dòng)帶出注釋,方便你的開(kāi)發(fā)。以protected,protected Internal,public聲明的定義注釋都建議以這樣命名方法。
例如:
- ///
- /// 用于從ERP系統(tǒng)中撈出產(chǎn)品信息的類
- ///
- class ProductTypeCollector
- {
- …
- }
2.3、邏輯點(diǎn)注釋在我們認(rèn)為邏輯性較強(qiáng)的地方加入注釋,說(shuō)明這段程序的邏輯是怎樣的,以方便我們自己后來(lái)的理解以及其他人的理解,并且這樣還可以在一定程度上排除BUG。在注釋中寫(xiě)明我們的邏輯思想,對(duì)照程序,判斷程序是否符合我們的初衷,如果不是,則我們應(yīng)該仔細(xì)思考耀修改的是注釋還是程序了…
3、排版
我的排版原則與建議:
1、 每行語(yǔ)句至少占一行,如果語(yǔ)句過(guò)長(zhǎng)(超過(guò)一屏),則該語(yǔ)句斷為兩行顯示;
2、 把相似的內(nèi)容放在一起,比如數(shù)據(jù)成員、屬性、方法、事件等,并適當(dāng)?shù)氖褂?region…#endregion,我最喜歡把機(jī)器生成的代碼都放在一個(gè)#region里面,比如在編寫(xiě)ASP.NET程序時(shí),對(duì)應(yīng)自動(dòng)產(chǎn)生的控件定義,我常用#region Automatic Generated Web Components … #endregion把他們框住
3、 使用空格,
(1) 雙目操作符的前后加空格(+, =, && 等),index = index + 1;
(2) 單目操作符前加空格(!, ++, ~ 等), index ++;
(3) 逗號(hào)、分號(hào)只在后面加空格
4、 使用空行,在一段功能代碼、或者函數(shù)、屬性之間插入空行,這樣會(huì)很直觀。
在Visual Studio 2005中,其實(shí)已經(jīng)帶有代碼格式化這樣的功能,快捷鍵是Ctrl+K -> Ctrl+D。
4、界面控件命名
我的建議是使用默認(rèn)控件名作為前綴,前綴名稱全部小寫(xiě),這樣的好處是不必為未知的控件統(tǒng)一命名方式發(fā)愁,比如對(duì)于Label標(biāo)簽控件,有的人用縮寫(xiě)lbl,有的人用lab,有的人用lb。這樣其實(shí)仍然是避免使用縮寫(xiě),有的時(shí)候仍然會(huì)使命名變得冗長(zhǎng),但是命名更加能反應(yīng)出變量的意義,并且各個(gè)開(kāi)發(fā)人員也能更好的執(zhí)行,因?yàn)樗麄儾恍枰ケ秤浉鱾€(gè)變量的縮寫(xiě)。
protected System.Web.UI.WebControls.Button buttonQuery;
protected System.Web.UI.WebControls.DropDownList dropdownlistProductType;
protected System.Web.UI.WebControls.TextBox textboxManufactureDate;
5、代碼可讀性一些建議
(1)注意運(yùn)算符的優(yōu)先級(jí),我們應(yīng)該盡量使用括號(hào)明確表達(dá)式的操作順序,避免使用默認(rèn)優(yōu)先級(jí),給我們以及維護(hù)人帶來(lái)困擾
(2)避免使用不易理解的數(shù)字,用有意義的標(biāo)識(shí)來(lái)替代(枚舉和常量)
比如:
if(productType == 0) … else if (productType == 1) … (不推薦使用) |
if(productType == ProductType.CD) … else if (productType == ProductType.DVD) … (推薦使用) |
(3)在界面層中盡量使用異常處理try語(yǔ)句,不要將系統(tǒng)級(jí)別的錯(cuò)誤直接暴露給用戶,而更應(yīng)該的是把系統(tǒng)拋出的錯(cuò)誤信息記錄到LOG日志文件中去,告訴用戶友好的提示信息
在Visual Studio 2005里面,有代碼布局格式化功能,蠻有用的。其實(shí)C#命名規(guī)約是為了使系統(tǒng)具有整體一致的編碼風(fēng)格,以使后期維護(hù)人員能更快的讀懂代碼并進(jìn)行維護(hù)。我認(rèn)為代碼規(guī)范有其必要性,但不能因?yàn)橐?guī)范而規(guī)范,從開(kāi)發(fā)而言,開(kāi)發(fā)是為了更快的做出穩(wěn)定的系統(tǒng),而穩(wěn)定的系統(tǒng)是為了給公司帶來(lái)受益。開(kāi)發(fā)人員、項(xiàng)目管理人員都應(yīng)該更多的從項(xiàng)目經(jīng)營(yíng)的角度出來(lái),同時(shí)站在公司、客戶的角度考慮問(wèn)題,而不是因?yàn)榇a而代碼。
本文來(lái)自Olay2008的博客園文章《C#命名規(guī)范》
【編輯推薦】