NET C# 开发人员遵循规范.docx

NET C# 开发人员遵循规范.docx

《NET C# 开发人员遵循规范.docx》由会员分享，可在线阅读，更多相关《NET C# 开发人员遵循规范.docx（11页珍藏版）》请在冰豆网上搜索。

NETC#开发人员遵循规范

前言

此规范分为四部分：

文档规范、结构规范、注释规范、命名规范。

文档规范

每个开发项目必须含有以下两个文档：

需求文档、数据库说明文档。

需求文档

由产品经理提供，该文档应需求清晰明了，多以图文结合的方式描述需求。

项目开发完成之后，将由开发者对该文档进行打分，用于体现该文档中包含的内容与实际开发过程中的功能的差异程度。

数据库说明文档

一份描述数据库各类信息的文档，如数据库表结构信息、存储过程和函数信息、视图信息、任务信息等。

其中，不建议以中文拼音首字母的方式来进行命名。

但出于对“原有项目”不适合调整的考虑，若数据库中含“以中文拼音首字母”命名的方式，则需要额外提供一份“命名说明对照表”。

项目结构规范

解决方案和项目的命名规范

解决方案名称应当能够完整表述系统的总体功能，如咨询企业信用档案管理系统，其解决方案名称可以为“ConsultingCompanyCreditFilesManageSystem”。

有时需要加上软件公司的标识，如“PMSoftConsultingCompanyCreditFilesManageSystem”。

这种需要添加软件公司标识的命名方式，也可以用“_”连接软件公司标识和系统名称。

项目名称应当体现项目的总体功能，并加上“解决方案名称简写”作为前缀，再以“.”连接。

如工具类的项目名可以是”PMSoft.Utility”。

由于工具类库是公用的，并不挂在某个系统项目之下，所以命名时可以用软件公司标识作为前缀。

而涉及到具体系统功能时的项目名称，则应该像这样：

CCCF.Entity、CCCF.Dto、CCCF.DataCore、CCCF.WebClient

项目数目较多时，可以用“解决方案文件夹”来隔离不同级别的项目。

如：

基础设施层，用于存放公共工具类、基础类源码等项目；

框架核心层，用于存放项目主业务框架层源码等项目；

项目结构规范

主要指同类文件的存放路径应该相同或类似，方便查找和整理。

如：

WebClient层中，js资源文件应该存放在项目根目录/Scripts下，可继续按类别不同用不同的文件夹分类，参考下图

WebClient层中，css资源文件应该存放在项目根目录/Content（或styles）下，可继续按类别不同用不同的文件夹分类，参考下图

注释规范

文件头注释

大部分情况下，请对各类文件提供文件头信息，格式大约如下：

标准注释

标准注释必须写，主要指类中各成员的注释（字段、属性的说明、方法的注释（方法用途说明、参数说明、返回结果说明）、事件的注释）、枚举的注释。

例如下图：

过程注释

当某个方法中的逻辑比较复杂（凭个人经验判定，如想象其他同事看这段代码，是否会无法快速确定代码要表述的意思），请按复杂程度和个人经验，补充过程注释，尽可能地对“你认为比较容易搞混搞错的关键代码”进行过程注释。

如下图：

命名规范

常见命名规则总览

Pascal命名规则、大驼峰命名规则

每个词首字母均为大写，如：

ServiceName

MethodInfo

UserName

IdCardNumber

小驼峰命名规则

第一个词的字母均为小写，其他每个词首字母均为大写，如：

serviceName

methodInfo

userName

idCardNumber

匈牙利命名规则

首字母区别数据类型，后面跟Pascal命名规则，如：

iNumber

sName

Capitalised命名规则

所有首字母均为大写，词与词之间用“_”连接，如：

SERVICE_NAME

METHOD_INFO

USER_NAME

ID_CARD_NUMBER

命名应遵循的共性规范

命名规范适用于开发中大部分地方（如类、方法、属性、字段、事件等）的命名。

具体介绍规范如下：

1-简单明了，望文知意。

应该采用英文单词。

切忌使用汉语拼音来命名。

程序中的英文单词一般不要太复杂，用词应当准确。

例如不要把CurrentValue写成NowValue。

变量涵义应该尽量反应真实世界的意义，而不是计算机世界的意义，如：

PrimaryFlag应该更正为IsPrimary。

变量名称应该描述是什么（what），而不是描述怎么做（how）。

2-长度应当符合“min-length&&max-information”原则。

一般的讲，长名字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为怪。

但是名字也不是越长越好。

例如：

变量名maxValue就比maxValueUntilOverflow更好用。

对于常用的缩写词，如果只有两个字母，则用大写表示，如ID；三个字母以上的词，则按照标准的大小写规则，如Xml。

3-不要出现仅靠大小写区分的标识符。

例如：

intx和intX；voidfoo（）和voidFOO（）等。

4-避免在不同级别的作用域中重名。

程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者因作用域的不同而不会发生语法错误，但会使人产生误解。

5-正确命名具有互斥意义的标识符。

如：

"MinValue"和"MaxValue"，"GetName（）"和"SetName（）"。

6-尽量避免名字中出现数字编号。

如Value1,Value2等，除非逻辑上的确需要编号。

这是为了防止程序产生无意义的名字，降低程序的可读性。

命名应遵循的细则规范

1）注意不能使用开发语言的关键词作为变量名称，如int、string、byte等。

2）数组和集合类型的变量名称最后应当加s，表示这个类型的复数，如string[]UserNames,ListNumbers。

3）在面向对象的语言中，在类的属性的名称中包含类名是多余的，如Book.BookTitle应该更正为Book.Title。

4）只要合适，在变量名称的末尾或开头加计算限定符号，如Avg、Sum、Min、Max、Index。

5）布尔类型的变量名称中应该包含Is，这意味着Yes/no或True/Flase值，如FileIsFound、IsExist。

6）可能的情况下，尽量不要使用原义数字或原义字符串，而使用命名常数，以便于维护和理解。

如for（inti=1;i<7;i++）应该更正为for（intI=1;i

“正常”:

“未激活”应该更正为User.State==UserNormalState?

“正常”:

“未激活”。

7）有时需要用到临时变量，这些变量一般采用加temp的方式来区别。

各种命名规则的使用说明

什么时候采用哪种命名规则，可参见下表。

要命名的对象

采用的命名规则

注意事项

示例

解决方案、项目、命名空间

Pascal

首字符大写

FilesManageSystem

类或结构

Pascal

首字符大写

StringExtensions、UserService

公共字段（类成员之一）

Pascal

首字符大写

UserName

属性（类成员之一）

Pascal

首字符大写

ID、Name、GatherAreaIds

与公共属性配对的私有字段

小驼峰

首字符小写，并在变量名之前加“_”

_fileName

方法（类成员之一）

Pascal

首字符大写

GetUserInfo、GetUserList

方法的参数

小驼峰

首字符小写

userId、parentCode

事件、委托

Pascal

首字符大写

PropertyChangedEventHandler

接口

匈牙利，并且首字母为I

首字符为大写I

IInitialize、IRepositories

局部变量

小驼峰

首字符小写

userList、allTypes、userId

枚举名、枚举值

Pascal

首字符大写

UserType、Sex

脚本语言（script）中所有

小驼峰

首字符小写

data、options

常用的变量命名应遵循的规范

接口定义

1）使用Pascal规则，并且首字母必须为“I”（大写的i）。

2）接口名称要有意义，中间不要有下划线“_”等字符。

3）如果类实现了接口，名称尽量和接口相同，只是省掉“I”字符。

4）注意接口修饰符只能用public和internal。

类定义

1）使用Pascal规则。

2）使用能够反映类功能的名词或名词短语命名类。

3）类名的单词之间，不要加连接符。

4）类的文件名要能反映类的内容，最好是和类同名。

5）一个类如果可以序列化，请添加特性[Serializable]。

6）异常类，名称加后缀Exception；属性类，名称加后缀Attribute；控制器类，名称加后缀Controller。

7）一个类如果肯定不再被继承，请添加关键字sealed，表示这是个密封类。

8）一个类如果肯定不能被实例化，请添加关键字abstract，表示这是个抽象类。

9）请明确类的访问修饰符，public、internal。

方法（类成员之一）定义

1）方法名使用Pascal规则。

2）方法名一般是一个动词短语或动宾结构的短语，如GetName、GetUserList、CheckUserNameIsExist。

3）类中访问修饰符或功能相同的方法应该放在一起，如有必要可用region折叠，且公共或实现接口的方法在前。

方法的参数定义

1）使用小驼峰规则。

2）使用描述性参数名称，参数名称应当具有最够的说明性。

3）不要给参数加匈牙利语类型表示法的前缀，如strName是没有意义的，因为参数类型中已经体现了该参数的数据类型。

4）方法的参数，在使用前应当有校验操作。

对于开发中可能会写错而现实使用中不会出错的参数，可以使用Assert方法校验，用它校验的好处是，在Release编译方式下这些代码不会执行。

对于一般的参数，可用if校验。

属性（类成员之一）定义

1）使用Pascal规则。

2）尽量采用名词或名词短语。

3）尽量不要将类名称体现在属性名中。

字段（类成员之一）定义

1）使用小驼峰规则。

2）如果有一个对应的属性定义，该字段定义应该在名称前加“_”，如属性UserName和字段_userName。

局部变量定义

1）使用小驼峰规则，即第一个词都小写，后面的词首字母大写。

2）对于不需要特殊含义的变量可以用简短变量代替，如i，k，m。

3）一组同类型的变量定义，尽量放在一起。

常量（包含只读常量、枚举、静态字段、静态属性等）定义

1）均使用Pascal规则。

2）枚举：

枚举的名称一般使用单数名称。

3）枚举：

枚举值从小到大顺序定义。

4）枚举：

缺省值的定义，请放在第一个位置。

5）枚举：

对于允许位计算的枚举，枚举的值应该是2的幂次方依次增加（如1，2，4，8），并需要给枚举类型添加特性[Flags]。

6）枚举：

可以为枚举变量名加前缀Enum，也可以不加，看项目规范。

关于方法和属性的访问修饰符

方法和属性都有作用范围，在.Net中有publicprotectedprivateinternal四种访问修饰符，应当熟悉它们的作用域，在开发过程中合理使用，如对于不公开的属性就采用protected或private。

关于方法和属性的修饰符

在.Net中有abstractstaticvirtualoverride四种修饰符，应当熟悉它们的作用和使用场景，在开发过程中合理使用，如对于一个基类就采用abstract修饰符，以保证该基类不会被实例化。