饱满骑士团队第六次作业—beta冲刺+事后诸葛亮：代码规范
1代码格式与风格
代码的格式包括缩进、换行、空行、空格等，为了保持一致的代码风格并且不影响编码的效率，所有开发人员统一使用VS默认的格式化（Ctrl+K+D）。
2命名规范
2.1大小写约定
使用下面的三种大写标识符约定：
PascalCasing（帕斯卡命名法）
PascalCasing约定被用于除了参数名之外的所有标识符，把标识符中每个单词的首字母(包括长度为两个字符以上的首字母缩写词)大写。例如：
PropertyDescriptor
UserName
camelCasing 大小写（驼峰命名法）
标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：
userName
大写
两个字母长的首字母缩写词是一个特例，在这种情况下两个字母都要大写。例如：
System.IO;
System.Web.UI;
IOStream
2.2类命名指南
以下规则概述命名类的指南：
-
使用名词或名词短语命名类。
-
使用 Pascal 大小写。
-
少用缩写。
-
不要使用类型前缀，如在类名称上对类使用 C 前缀。例如，使用类名称 FileStream，而不是 CFileStream。
-
不要使用下划线字符 (_)。
-
有时候需要提供以字母 I 开始的类名称，虽然该类不是接口。只要 I 是作为类名称组成部分的整个单词的第一个字母，这便是适当的。例如，类名称 IdentityStore 是适当的。
-
在适当的地方，使用复合单词命名派生的类。派生类名称的第二个部分应当是基类的名称。例如，ApplicationException 对于从名为 Exception 的类派生的类是适当的名称，原因是 ApplicationException 是一种 Exception。请在应用该规则时进行合理的判断。例如，Button 对于从 Control 派生的类是适当的名称。尽管按钮是一种控件，但是将 Control 作为类名称的一部分将使名称不必要地加长。
2.3接口命名指南
以下规则概述接口的命名指南：
-
用名词或名词短语，或者描述行为的形容词命名接口。例如，接口名称 IComponent 使用描述性名词。接口名称 ICustomAttributeProvider 使用名词短语。名称 IPersistable 使用形容词。
-
使用 Pascal 大小写。
-
给接口名称加上字母
I前缀，以指示该类型为接口。 -
在定义类/接口对（其中类是接口的标准实现）时使用相似的名称。两个名称的区别应该只是接口名称上有字母
I前缀。 -
不要使用下划线字符 (_)。
2.4枚举类型命名指南
枚举 (Enum) 值类型从 Enum 类继承。以下规则概述枚举的命名指南：
-
对于 Enum 类型和值名称使用 Pascal 大小写。
-
少用缩写。
-
不要在 Enum 类型名称上使用
Enum后缀。 -
对大多数 Enum 类型使用单数名称，但是对作为位域的 Enum 类型使用复数名称。
-
总是将 FlagsAttribute 添加到位域 Enum 类型。
2.5静态字段命名指南
以下规则概述静态字段的命名指南：
-
使用名词、名词短语或者名词的缩写命名静态字段。
-
使用 Pascal 大小写。
-
建议尽可能使用静态属性而不是公共静态字段。
2.6参数命名指南
以下规则概述参数的命名指南：
-
使用描述性参数名称。参数名称应当具有足够的描述性，以便参数的名称及其类型可用于在大多数情况下确定它的含义。
-
对参数名称使用 Camel 大小写。
-
使用描述参数的含义的名称，而不要使用描述参数的类型的名称。开发工具将提供有关参数的类型的有意义的信息。因此，通过描述意义，可以更好地使用参数的名称。少用基于类型的参数名称，仅在适合使用它们的地方使用它们。
-
不要使用保留的参数。保留的参数是专用参数，如果需要，可以在未来的版本中公开它们。相反，如果在类库的未来版本中需要更多的数据，请为方法添加新的重载。
-
不要给参数名称加匈牙利语类型表示法的前缀。
2.7方法命名指南
以下规则概述方法的命名指南：
-
使用动词或动词短语命名方法。
-
使用 Pascal 大小写。
2.8属性命名指南
以下规则概述属性的命名指南：
-
使用名词或名词短语命名属性。
-
使用 Pascal 大小写。
-
不要使用匈牙利语表示法。
-
考虑用与属性的基础类型相同的名称创建属性。例如，如果声明名为 Color 的属性，则属性的类型同样应该是 Color。
2.9事件命名指南
以下规则概述事件的命名指南：
-
对事件处理程序名称使用
EventHandler后缀。 -
指定两个名为 sender 和 e 的参数。sender 参数表示引发事件的对象。sender 参数始终是 object 类型的，即使在可以使用更为特定的类型时也如此。与事件相关联的状态封装在名为 e 的事件类的实例中。对 e 参数类型使用适当而特定的事件类。
-
用 EventArgs 后缀命名事件参数类。
-
考虑用动词命名事件。
-
使用动名词（动词的“ing”形式）创建表示事件前的概念的事件名称，用过去式表示事件后。例如，可以取消的 Close 事件应当具有
Closing事件和Closed事件。不要使用BeforeXxx/AfterXxx命名模式。 -
不要在类型的事件声明上使用前缀或者后缀。例如，使用
Close，而不要使用OnClose。 -
通常情况下，对于可以在派生类中重写的事件，应在类型上提供一个受保护的方法（称为 OnXxx）。此方法只应具有事件参数 e，因为发送方总是类型的实例。
3注释规范
3.1模块（类）注释规范
模块开始必须以以下形式书写模块注释：
///
///模块编号：<模块编号，可以引用系统设计中的模块编号>
///作用：<对此类的描述，可以引用系统设计中的描述>
///作者：作者中文名
///编写日期：<模块创建日期，格式：YYYY-MM-DD>
///
如果模块有修改，则每次修改必须添加以下注释：
///
///Log编号：<Log编号,从1开始一次增加>
///修改描述：<对此修改的描述>
///作者：修改者中文名
///修改日期：<模块修改日期，格式：YYYY-MM-DD>
///
3.2类属性注释规范
在类的属性必须以以下格式编写属性注释：
///
///类说明
///
3.3方法注释规范
在类的方法声明前必须以以下格式编写注释
///
/// 说明：<对该方法的说明>
///
/// <参数说明>
///
///<对方法返回值的说明，该说明必须明确说明返回的值代表什么含义>
///
3.4代码间注释规范
代码间注释分为单行注释和多行注释：
单行注释：
//
多行注释：
/*多行注释1
多行注释2
多行注释3*/
