《.Net设计规范-约定、惯用法与模式》部分摘记

2011-01-04

15:59:54

[第二章.框架设计基础]

    过分使用泛型和继承是抽象过度的常见的症状。

    为广大的开发人员构建单个框架的一般规范是：把API划分成低层类型和高层类型。低层类型保护丰富的API并提供强大的功能，而高层类型则用便利的API对低层API进行封装。使高层API提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。

 

2011-01-05

11:31:52

[第三章.命名规范]
[注意：公开的成员需遵守，私有成员无需遵守]

程序集和DLL的命名：
一般规则:<Company>.<Component>.dll，Component包含一个或多个以原点分隔的字句。
经验法则：根据程序集中名字空间的公共前缀来命名Dll
名字空间的命名:
一般规则：<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
原则： 

 1.不要根据公司的组织架构来决定层次结构
 2.要使用PascalCasing大小写风格
 3.要适当的使用复数形式
 4.不要有类型和空间名的名字冲突
 5.名字空间要一般化。而类型名字要非一般化，可在一般化名字前加上限定符

类、结构和接口的命名：
原则： 

 1.类和结构要用名词和名词短语，接口要用形容词短语。
 2.不要给类名加前缀(例如C)
 3.考虑派生类的末尾使用基类的名字
 4.要让接口以字母I开头
 5.要确保一对类/接口的名字只差一个字母I的前缀 ，前提为该类是该接口的标准实现

枚举类型的命名：
原则： 

 1.单数名词表示枚举类型，复数名词表示位域的枚举类型(标记枚举)
 2.不要给枚举类型的名字添加"Enum"后缀、"Flag"、"Flag"后缀、前缀

类型的命名：
原则： 

 1.不要给不同层的名字空间中的类型起相同的名字

类型成员的命名：
原则：

 1.方法的命名，必须是动词或动词短语，让方法名和他执行的任务直接对应，而不是和他的实现细节对应。
 2.属性的命名，必须是名词短语或形容词。
 3.不要让属性名看起来于"Get"方法的名字相似，例TextWriter和GetTextWriter
 4.要用项目短语的复数形式来命名集合属性，而不是用项目短语加List或Collection后缀。例Items，而不是ItemCollection.
 5.布尔属性要用肯定性的短语，有选择性地给布尔属性添加"Is"(是+形容词)、"Can"(能+动词)、"Has"(有+名词)等前缀，注意前缀通常是多余的，这时没必要添加。
 6.考虑用属性的类型来命名属性的名字。
 7.事件的命名，要用动词或动词短语。
 8.要用现在时和过去时赋予事件名以之前之后的概念，用动词的时态来表示事件发生的事件。
 9.不要用"Before"或"After"前缀或后缀来区分前置和后置，而要用现在时和过去时。
 10.要在命名事件处理函数(用作事件类型的委托)时加上"EventHandler"后缀，注意应该避免创建自定义的事件处理函数。
 11.要在事件处理函数中用sender和e作为两个参数的名字。
 12.要在命名事件的参数类时加上"EventArgs"后缀。
 13.字段的命名，要用名词、名词短语或形容词来命名，使用camelCasing大小写风格。
 14.不要给字段名添加前缀,例如"g_"、"s_"表示静态。(私有的建议添加前缀)
 15.参数名应该具备足够的描述性，并且应该描述语义，而不是描述类型。
 16.如果参数没有具体含义，二元参数则用left、right,一元参数则用value。
 17.不要在命名重载操作符的参数时，使用缩写或者数字编号。