c# 编码规范
c# 编码规范 1
1 命 名 约 定 4
1.1 常用命名术语说明 4
1.2 名称空间命名 4
1.3 类命名 4
异常类命名 5
1.4 局部变量命名 5
1.5 只读静态变量 5
1.6 类私有变量 5
1.7 属性命名 5
1.8 接口命名 5
1.9 方法命名 6
参数 6
1.10 结构 6
1.11 事件命名 6
1.12 枚举类型 6
1.13 委托命名delegate 6
1.14 类对象命名 6
1.15 Attribute 7
1.16 控件命名 7
1.17 大小写敏感 8
1.18 缩写简写规则 8
1.19 使用统一的量尺 9
1.20 ID命名 9
2 代码格式化 9
2.1 要达到的目的 9
2.2 ｛｝的位置 9
2.3 if、if else的格式 10
2.4 for、foreach的格式 10
2.5 while／do－while的格式 11
2.6 switch的格式 11
2.7 try的格式 12
2.8 空格 13
2.9 在执行统一任务的各个语句组之间插入一个空行。好的代码应由按逻辑顺序排列的进程或相关语句组构成。 14
2.10 名称空间写法 14
2.11 ＃region写法 14
3 代码注释 14
3.1 注释的目的 14
3.2 函数体内的注释 14
3.3 对类文件进行属性注释说明 14
3.4 避免对很显然易懂的语句进行注释说明 15
3.5 代码应该能作到自我解释代码作用的功能。 15
3.6 逻辑点内注释 15
3.7 注释来说明何时可能出错和为什么出错 15
3.8 在编写代码前进行注释 15
3.9 纯色字符注释行只用于主要注释 15
3.10 避免形成注释框 15
3.11 注释那些部分 15
3.12 增强注释的可读性 17
3.13 对注释进行缩进，使之与后随的语句对齐 17
3.14 请在每个if语句的前面加上注释 17
3.15 在每个switch语句的前面加上注释 17
3.16 在每个循环的前面加上注释 17
3.17 如果一个程序块内有多个尾随注释，每个注释的缩进应该保持一致 18
4 错误与异常处理 18
4.1 采用适当的日志机制来报告异常 18
4.2 只对错误采用异常处理 18
4.3 不要使用异常实现来控制程序流程结构 18
4.4 只捕捉特定的异常，而不是一般的异常。 18
4.5 别写太大的 try-catch 模块 19
4.6 自定义异常类 19
5 类成员设计 20
5.1 设计类和方法时，要达到下列目的 20
创建更加容易调试和维护的方法 20
创建具有强大内聚力的类 20
创建高度专用的方法 20
创建松散连接的方法 20
尽量使方法具有独立性 20
提高方法的扇入性 20
降低方法的扇出性 20
5.2 名称空间引用 20
在代码里，避免使用类似 System.Web.WebUIControls.Page 这样完整的引用名称，而应在顶部用 using 声明 System.Web.WebUIControls，而后以 Page进行编码 21
5.3 类设计 21
创建具有强大内聚力的类 21
成员排列规则 21
自定义属性类必须以 Attribute 为后缀，如 SomeAttribute 22
自定义错误异常类必须以 Exception 为后缀，如SomeException。 22
在泛型(Generics)代码里，类型参数均以 Type 为后缀的一个名词来命名 22
每个类文件名应尽量保持与内部类名一致 23
尽量避免手动去修改工具环境自动生成的代码 23
避免在一个类文件里放置多个类 23
一个类文件里应该有且仅有一个命名空间，避免在一个类文件里包含多个不同的命名空间 23
避免在一个类文件里代码超过 500 行（除去自动生成的代码） 23
尽量使用类库包含程序的业务逻辑，以使应用程序集代码最小化 23
数据结构里，应该总是更倾向使用C#的范型generic 23
尽量缩小变量的作用域 23
5.4 接口设计 23
每个接口不应当有超过20个成员的情况，一般应保持在12个左右 24
避免使用事件作为接口成员 24
避免使用抽象方法，而用接口替代 24
5.5 方法设计 24
创建松散连接和高度专用的方法 24
使所有方法都执行专门的任务 24
尽量使方法成为自成一体的独立方法 25
有返回值的方法必须在方法命名里包含对该返回值的信息描述，如GetObjectStat()。 25
局部变量的声明，应尽可能紧靠在它首次被使用的地方 25
一个方法里的代码避免超过 25 行，最多不能超过 50 行（除去空行、注释） 25
一行代码最多不要超过 80 个字符 25
利用Debug类对每个假设应进行条件检查 25
声明变量或方法为public类型应尽量谨慎，避免暴露过多不必要的细节 25
尽量不要在代码内进行硬编码，应该用const将之声明为常量变量 25
利用Debug类对每个假设应进行条件检查 25
总使用以 0 为第一个数标的数组 26
尽量不要使用 goto 语句 26
避免直接用方法作为条件语句里的Boolean值进行判断 26
对于引用类型的数组的初始化，必须总是用for或foreach语句循环初始化 26
应该也尽量避免直接使用方法做为返回值，为每个方法赋予单个退出点 27
将某些信息（如错误提示信息）直接传递给最终用户 27
避免使用强制转换，推荐使用as操作符进行防御性转换 27
当需要创建一个长字符串时，推荐使用StringBuilder，而非string 27
this用法 27
避免使用不易理解的数字，用有意义的标识来替代（枚举和常量） 28
用参数在方法之间传递数据 28
5.6 属性设计 28
5.7 事件设计 29
5.8 其他规则 29
6 项目环境设置 29
7 违背规范 31
查询此规范详细文档建议使用文档结构图形式(菜单 -> 视图 -> 文档结构图)
1 命 名 约 定
1.1 常用命名术语说明
术语 说明
Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用 Pascal 大小写。例如：BackColor
Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：backColor
1.2 名称空间命名
NET Framework 类型使用点语法命名方案，该方案隐含了层次结构的意思。此技术将相关类型分为不同的命名空间组，以便可以更容易地搜索和引用它们。全名的第一部分（最右边的点之前的内容）是命名空间名。全名的最后一部分是类型名。例如，System.Collections.ArrayList 表示 ArrayList 类型，该类型属于 System.Collections 命名空间。System.Collections 中的类型可用于操作对象集合。此命名方案使扩展 .NET Framework 的库开发人员可以轻松创建分层类型组，并用一致的、带有提示性的方式对其进行命名。库开发人员在创建命名空间的名称时应使用以下原则：
“公司名称.技术名称.软件产品代号”或“公司名称.产品技术代号”
例如，Nd.ClassLibrary.Charting 命名空间就表示Nd公司里的公用类库里的Charting画图类库。又如Nd.91Net.GovernmentInfoSharing表示Nd公司里的91平台大项目里的政务信息发布与服务系统 。
又如： net91com.Movies.DataAccess 名称空间标识 91.COM 电影站的数据访问层程序集。
|
|
资源大小：476.90 KB 
