一組一致的的命名約定對框架的可用性及其重要。 名字要易於理解,同時必須傳達每個元素的功能。
.NET命名規範之大小寫約定
標識符的大小寫規則
◆PascalCasing:如HtmlTag IOStream
◆camelCasing:如htmlTag ioStream
◆要把PascalCasing用於由多個單詞構成的名字空間、類型、以及成員的名字;
◆要把camelCasing用於參數的名字。
.NET命名規範之通用命名約定
單詞的選擇
對框架中標識符的名字來說,很重要的一點是一目瞭然。
名字的意思清楚比長度短更重要。名字應該與場景、系統的邏輯組成或物理組成以及爲人熟知的概念相對應,而不應該與技術或框架相對應。
◆要爲標識符選擇易於閱讀的名字;
◆要更看重可讀性,而不是更看重簡短性;
◆不要使用下劃線、連字符以及其他任何既非字母也非數字的字符;
◆不要使用匈牙利命名法;
◆避免使用與廣泛使用的編程語言的關鍵字有衝突的標識符。
◆使用單詞縮寫和首字母縮寫詞
一般來說,不要在標識符中使用單詞縮寫或首字母縮寫:寧可名字長一點,也不要別人看不懂。 尤其不要使用未被廣泛接受的單詞縮寫和首字母縮寫詞。
◆不要使用縮寫詞或縮略詞作爲標識符名字的一部分
◆用GetWindow 不用GetWin
◆不要使用未被廣泛接受的首字母縮寫詞
何謂廣泛接受:用搜索引擎在網上搜索該首字母縮寫詞,如果返回的前幾個結果與期望相符,那麼該首字母縮寫詞纔有資格被稱爲衆所周知。
◆避免使用語言特有的名字
◆要給類型名使用語義上有意義的名字,而不要使用特有的關鍵字
◆GetLength比GetInt要好
◆要使用CLR的通用類型名,而不要使用語言特有的別名
◆要使用常見的名字,比如value或item,而不要重複類型的名字
爲已有API的新版本命名
當用新類型和新成員接替或取代已有的類型或成員時,如何選擇名字:
◆使用與舊API相似的名字
◆要優先使用後綴而不是前綴來表示已有API的新版本
這樣有助於在瀏覽文檔或使用Intellisense時發現新版本:按字母排序
◆可以考慮使用全新但有意義的標識符
◆要使用數字後綴來表示已有API的新版本
◆有些名字(或工業標準)不宜添加後綴或改名
◆不要在標識符中使用“Ex”“New”等類似的後綴來區分相同API的不同版本
◆要在引入64位整數(long)而非32位整數進行操作的新版本API時使用“64”後綴,反之亦然。
.NET命名規範之程序集和DLL的命名
程序集是一個部署單元,同時還代表託管代碼程序的身份。雖然程序集可以分佈一個或多個文件中,但一般來說一個程序集僅與一個DLL相對應。
名字空間與DLL程序集的區別:
◆名字空間:一組邏輯實體
◆DLL和程序集:打包和部署時的一個單
◆要爲程序集和DLL選擇提示性的名字,比如System.Data,這樣很容易就知道它的大致功能。
◆DLL命名:< Company>.< Component>.dll
.NET命名規範之名字空間的命名
< Company>.(< Product>|< Technology>)[.< Feature>][.< Subnamespace>]
◆要用公司名稱作爲名字空間的前綴,不要用縮寫
◆要用穩定的與版本無關的產品名稱作爲名字空間的第二層
◆不要根據公司的組織架構來決定名字空間的層次結構,因爲公司內部組織的名稱一般來說不會持續太長的時間
◆要使用PascalCasing大小寫風格,並用點號來分隔名字空間的各部分。
如Microsoft.Office.PowerPoint
◆考慮適當的時候在名字空間中使用複數形式。 首字母縮寫詞例外
System.Collections
System.IO
◆不要用相同的名字來命名名字空間與位於該名字空間中的類型
如:不要將名字空間命名爲Debug,然後又在該名字空間中提供一個名爲Debug的類。
名字空間和類型衝突
◆不要引入太一般化的類型名,比如Element、Node、Log以及Message。
◆不同類型的名字空間,有不同的規範來避免類型名的衝突:
應用程序模型名字空間(application model namespace)
屬於單個應用程序模型的名字空間經常一起使用,但是它們幾乎不合屬於其他應用程序模型的名字空間一起使用
System.Windows*
System.UI*
基礎設施名字空間(infrastructure namespace)
此類別包含一些在開發常用應用程序時很少會導入的名字空間
核心名字空間(core namespace)
包含了所有的System名字空間,但應用程序模塊名字空間和基礎設施名字空間除外。 包括System、System.IO、System.Xml以及System.Net等等
技術名字空間組(technology namespace group)
此類別包含所有那些以相同的兩個前綴(< Company>.< Technology>*)開始的名字空間。
.NET命名規範之類、結構和接口的命名
一般來說類型名應該是名詞詞組。如果無法爲類型找到一個名詞詞組,那麼應該重新考慮類型的總體設計。
另一箇中重要的考慮因素:最易於識別的名字應該用於最常用的類型。
最常用的類型名應該反映出使用場景,而不是繼承層次。
要用名詞詞組來給類型命名。使用PascalCasing風格
不要給類名加前綴
只有接口才能(可以)被加前綴“I”,那是因爲.NET框架受到COM及Java的影響
考慮讓派生類的名字以其基類結尾
public class FileStream : Stream {...}
要確保一對類/接口的名字只差一個“I”前綴,如果該類是該接口的標準實現。
public interface IComponent {...}
public class Component : IComponent {...}
泛型類型參數的命名
要用描述性的名字來命名
考慮用T來命名參數類型
要給描述性的類型參數名加上T前綴
考慮在類型參數中顯示出施加於該類型參數上的限制
枚舉類型的命名
要用單數名詞來命名枚舉類型,除非它表示的是位域(bit field)
不要給枚舉類型的名字添加“Enum”後綴,也不要添加“Flag”、“Flags”等後綴
不要給枚舉類型值的名字添加前綴
此規範與C++中通常所使用的恰好相反。在C++中給枚舉的每個成員加上完成的限定符是很重要的,因爲它們可能在枚舉名的作用域之外被訪問。但是在託管代碼中,枚舉成員只能通過枚舉名的作用域來訪問。
.NET命名規範之類型成員的命名
類型:方法、屬性、事件、構造函數、字段
方法的命名
要儘量根據方法所對應的任務來給它們命名,而不要根據一些實現細節。
要用動詞或動詞詞組來命名方法
屬性的命名
要用名詞、名詞詞組或形容詞來命名屬性
不要讓屬性名看起來與“Get”方法的名字相似
要用肯定性的短語(CanSeek而不是CantSeek)來命名布爾屬性
考慮用屬性的類型名來命名屬性
public enum Color {...}
public class Control
{
public Color Color
{
get {...}
set {...}
}
}
事件的命名
要用動詞或動詞短語來命名事件
事件總是表示一些動作,要麼正在發生,要麼已經發生
要用現在時和過去時來賦予事件名之前和之後的概念
窗口關閉之前發生的close事件:Closing
窗口關閉之後發生的close時間:Closed
不要用Before和After前綴或後綴來區分前置和後置事件
要在命名事件處理函數(用作事件類型的委託)時加上“EventHandler”後綴
要在事件處理函數中用sender和e作爲兩個參數的名字
sender:觸發事件的對象,在整個.NET框架中,sender爲object類型
要在命名事件的參數類型時加上“EventArgs”後綴
字段的命名
PascalCasing風格
名詞或名詞短語
不要給字段名添加前綴
.NET命名規範之參數的命名
camelCasing風格
要使用描述性的參數名
參數名要具備足夠的描述性,使得在大多數情況下,用戶根據參數的名字和類型就能夠確定它的意思
考慮根據參數的意思而不是參數的類型來命名參數
.NET命名規範之資源的命名
本地化的資源就好比是屬性,可以通過特定的對象來引用。因此,它的命名規範與屬性的相似。
要在命名屬性關鍵字(resource key)時使用PascalCasing大小寫風格
要使標識符的名字具有描述性而不是使名字變短
不要使用各主要CLR編程語言特有的關鍵字
要在命名資源時使用字母、數字和下劃線
要用點號來給標識符清楚地劃分層次
要在爲異常消息資源命名是遵循下面的命名約定:
資源標識符應該是異常的類型名加一個簡短的異常標識符,之間以點號分隔