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