一组一致的的命名约定对框架的可用性及其重要。 名字要易于理解，同时必须传达每个元素的功能。

大小写约定

标识符的大小写规则

PascalCasing：如HtmlTag  IOStream

camelCasing：如htmlTag  ioStream

• 要把PascalCasing用于由多个单词构成的名字空间、类型、以及成员的名字；
• 要把camelCasing用于参数的名字。

通用命名约定

单词的选择

对框架中标识符的名字来说，很重要的一点是一目了然。

名字的意思清楚比长度短更重要。名字应该与场景、系统的逻辑组成或物理组成以及为人熟知的概念相对应，而不应该与技术或框架相对应。

• 要为标识符选择易于阅读的名字；
• 要更看重可读性，而不是更看重简短性；
• 不要使用下划线、连字符以及其他任何既非字母也非数字的字符；
• 不要使用匈牙利命名法；
• 避免使用与广泛使用的编程语言的关键字有冲突的标识符。

使用单词缩写和首字母缩写词

一般来说，不要在标识符中使用单词缩写或首字母缩写：宁可名字长一点，也不要别人看不懂。  尤其不要使用未被广泛接受的单词缩写和首字母缩写词。

• 不要使用缩写词或缩略词作为标识符名字的一部分
  用GetWindow  不用GetWin
• 不要使用未被广泛接受的首字母缩写词
  多谓广泛接受：用搜索引擎在网上搜索该首字母缩写词，如果返回的前几个结果与期望相符，那么该首字母缩写词才有资格被称为众所周知。

避免使用语言特有的名字

• 要给类型名使用语义上有意义的名字，而不要使用特有的关键字
  GetLength比GetInt要好
• 要使用CLR的通用类型名，而不要使用语言特有的别名
• 要使用常见的名字，比如value或item，而不要重复类型的名字

为已有API的新版本命名

当用新类型和新成员接替或取代已有的类型或成员时，如何选择名字：

• 使用与旧API相似的名字
• 要优先使用后缀而不是前缀来表示已有API的新版本
  这样有助于在浏览文档或使用Intellisense时发现新版本：按字母排序
• 可以考虑使用全新但有意义的标识符
• 要使用数字后缀来表示已有API的新版本
  有些名字（或工业标准）不宜添加后缀或改名
• 不要在标识符中使用“Ex”“New”等类似的后缀来区分相同API的不同版本
• 要在引入64位整数（long）而非32位整数进行操作的新版本API时使用“64”后缀，反之亦然。

程序集和DLL的命名

程序集是一个部署单元，同时还代表托管代码程序的身份。虽然程序集可以分布一个或多个文件中，但一般来说一个程序集仅与一个DLL相对应。

名字空间与DLL程序集的区别：

名字空间：一组逻辑实体

DLL和程序集：打包和部署时的一个单

• 要为程序集和DLL选择提示性的名字，比如System.Data，这样很容易就知道它的大致功能。
• DLL命名：<Company>.<Component>.dll

名字空间的命名

<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>*）开始的名字空间。

类、结构和接口的命名

一般来说类型名应该是名词词组。如果无法为类型找到一个名词词组，那么应该重新考虑类型的总体设计。

另一个中重要的考虑因素：最易于识别的名字应该用于最常用的类型。

最常用的类型名应该反映出使用场景，而不是继承层次。

• 要用名词词组来给类型命名。使用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++中给枚举的每个成员加上完成的限定符是很重要的，因为它们可能在枚举名的作用域之外被访问。但是在托管代码中，枚举成员只能通过枚举名的作用域来访问。

类型成员的命名

类型：方法、属性、事件、构造函数、字段

方法的命名

要尽量根据方法所对应的任务来给它们命名，而不要根据一些实现细节。

• 要用动词或动词词组来命名方法

属性的命名

• 要用名词、名词词组或形容词来命名属性
• 不要让属性名看起来与“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风格
• 名词或名词短语
• 不要给字段名添加前缀

参数的命名

• camelCasing风格
• 要使用描述性的参数名
  参数名要具备足够的描述性，使得在大多数情况下，用户根据参数的名字和类型就能够确定它的意思
• 考虑根据参数的意思而不是参数的类型来命名参数

资源的命名

本地化的资源就好比是属性，可以通过特定的对象来引用。因此，它的命名规范与属性的相似。

• 要在命名属性关键字（resource key）时使用PascalCasing大小写风格
• 要使标识符的名字具有描述性而不是使名字变短
• 不要使用各主要CLR编程语言特有的关键字
• 要在命名资源时使用字母、数字和下划线
• 要用点号来给标识符清楚地划分层次
• 要在为异常消息资源命名是遵循下面的命名约定：
  资源标识符应该是异常的类型名加一个简短的异常标识符，之间以点号分隔