.Net开发规范标准[详]

《.Net开发规范标准[详]》由会员分享，可在线阅读，更多相关《.Net开发规范标准[详]（49页珍藏版）》请在金锄头文库上搜索。

1、.net 开发规范 . . . . 参考.资料 目录目录 1.概述4 2.命名规范4 2.1指导性原则4 2.1.1使用正确的大小写风格4 2.1.2使用描述性英文名称4 2.1.3使用易读的名称4 2.1.4尽量避免在名称中使用编码5 2.1.5同义词中使用固定的单词5 2.1.6保持词义的前后一致5 2.1.7名词和动词的选用5 2.1.8使用计算机专业术语5 2.1.9必要时可使用业务术语6 2.1.10避免误导6 2.1.11名词需要语境说明6 2.1.12不要添加人为的语境6 2.1.13避免名称差别不明显造成混淆6 2.2大写风格6 2.2.1Pascal 风格 .7 2.2.2C

2、amel 风格 7 2.2.3大写风格7 2.2.4大写小结7 2.3单词选择8 2.3.1缩写8 2.4命名空间9 2.5类和类成员9 2.5.1类的命名指南9 2.5.2Attribute 命名指南 .10 2.5.3枚举命名指南.10 2.5.4静态类属性名.10 2.5.5参数名.10 2.5.6方法命名指南.11 2.5.7属性命名指南.11 2.5.8事件命名指南.11 2.6大小写敏感.12 3.程序注释规范.12 3.1注释编写准则.12 3.2模块注释.13 3.3类的注释.13 3.4类成员方法的注释.15 . . . . 参考.资料 3.5类成员属性、常量、变量的注释.1

3、6 3.6程序注释.16 4.代码书写规范.16 4.1排版规范.16 5.类成员使用规范.20 5.1属性使用指南.20 5.1.1只读和只写的属性.22 5.2事件使用指南.22 5.3方法使用指南.23 5.3.1方法重载指南.23 5.4构建函数使用指南.24 5.5类的成员变量使用指南.25 5.6参数名称指南.26 6.类型使用指南.27 6.1类使用指南.27 6.1.1基类使用指南.27 6.2值类型使用指南.28 6.2.1结构使用指南.28 6.2.2枚举使用指南.28 6.3程序代理使用指南.30 6.4程序属性(ATTRIBUTE)的使用 .30 7.异常的产生和处理.

4、30 7.1标准异常类型.33 7.2异常的包装 WRAPPING EXCEPTIONS34 8.数组使用指南.34 8.1数组VS. 集合.34 8.1.1集合.34 8.1.2集合中可索引的属性.34 8.1.3数组值属性.35 8.2返回空数组.35 9.数据库设计开发规范.35 9.1命名规范.35 9.2字段设计要求.36 9.3视图使用原则.36 9.4存储过程建立规则.36 9.5函数建立规则.36 9.6触发器使用要求.36 . . . . 参考.资料 1 1概述概述 在建设过程中，将涉及到在新的 Visual Studio.NET 以及.NET Framework 平台上的开

5、 发工作。同时，设计人员、开发人员和测试人员较多。为了使应用程序的结构和编码风格 标准化，便于阅读和理解编码，以提高开发效率和产品的标准化，制订一套开发规范和标 准势在必行。此外，好的编码约定可使源代码严谨、可读性强且意义清楚，与其它语言约 定相一致，并且尽可能的直观。希望开发人员严格遵守此套开发规范和标准，并落实到自 己的程序中。 一组通用目的的编码约定应该定义完成上述目的所必需的、能让程序员自由地创建程 序逻辑和功能流程的最小的要求。最小编码约定的目的是使程序易于阅读和理解，从而指 导程序员更好地完成开发任务。 本规范主要针对使用 Visual Studio.NET 以及.NET Fram

6、ework 开发的基于 Web 的应用 系统。 2 2命名命名规范规范 2.12.1 指导性原则指导性原则 命名是编程的核心。能够对变量和函数/过程进行表意清晰而准确的命名，就能使程序 的可读性大大提高，达到不说自明的效果。真正的名称是深入认真思考一个对象的生态环 境后才能给出的。程序设计人员只有在充分理解并把握整个系统时，才可能给出真正合适 的名字。如果名称选用恰当，一切就显得很自然，各部分关系清晰，意义可以推导而出， 阅读程序时可以按常识推理，从而减小程序员对已有程序的阅读和理解困难，提高工作效 率，使新程序员能在尽量短的时间内进入角色。 以下章节描述了程序命名的一些指导性原则。 2.1.

7、12.1.1使用正确的大小写风格使用正确的大小写风格 为保证良好的程序可读性，对命名的大小写必须按照一致的规定编写，主要包括 Pascal 风格和 Camel 风格两种，下面将会有专门的章节进行详细说明。 . . . . 参考.资料 2.1.22.1.2使用描述性英文名称使用描述性英文名称 为保证程序的可读性，要采用准确描述其意义的名字。英语是国际通用语言，绝大多 数商业类库或函数库代码都是由英语编写的。要与标准接轨，充分利用网上的程序资源， 应尽量使用英语命名。 2.1.32.1.3使用易读的名称使用易读的名称 如果不可读或不易读，则不便于讨论和交流。因此我们要尽量使用大众化名称，避免 使用

8、不常用的单词。 2.1.42.1.4尽量避免在名称中使用编码尽量避免在名称中使用编码 对名称使用编码就需解码才能理解。少数几个前缀字母有助于区分名称类别。但为了 追求风格而过分使用前缀和后缀就会造成生涩难懂的名字。例如 SRD2T3。含有编码的名称 一般都没有可读性。当然，任何编码，只要科学，时间久了都能被掌握。但是，掌握编码 需要新成员的额外精力，增加了适应难度，因此应尽量避免。 2.1.52.1.5同义词中使用固定的单词同义词中使用固定的单词 首先，我们应尽量使用英语词汇，因为汉语拼音实际上也是一种名称编码，特别是使 用拼音首字母，即使是懂汉语拼音的人也未必能理解。有了用英语命名的前提，我

9、们还应 该注意：一个抽象概念可能有多个表述同义词，选择一个，始终如一。如对同一动作，在 不同类中选用不同的名称，比如，fetch, retrieve 和 get，那么，使用你的类从事编程 的人就要多费很多精力去理解它们。也就是说，我们应该通过使用一致的名称，创建统一 的编程接口，简化学习的难度。 2.1.62.1.6保持词义的前后一致保持词义的前后一致 多数词都有不止一个意思，但在同一个系统中，应始终保持同一个意思。这和前面的 原则是相对应的。使用不同的词汇，使人联想不同的接口和/或操作。同样，使用同样的词 汇，使人联想相同的接口和/或操作。如果我学过使用 DeviceManager:add(

10、), 我就会期 望可以使用 ProtocolManager:add(). 这是根据名称产生的联想，甚至连想到可以使用 *Manager:add()。要保证这种联想能成立，前后词义必须一致。如果自己设计一个系统， . . . . 参考.资料 要尽量做到保持词义的一致。记住，在两个完全不同的范畴内使用相同的名字是很不可取 的。 2.1.72.1.7名词和动词的选用名词和动词的选用 类和对象应当使用名词或名词短语命名。方法中强调过程用动词，返回值用名词。作 为一名设计人员，可能不太在意这些命名的琐事。尝试使用你设计的类去编写一段用户程 序，看看有多少别扭或混乱的地方，一定可以反过来有助你改进设计。

11、2.1.82.1.8使用计算机专业术语使用计算机专业术语 尽量使用约定成俗的惯用语、计算机科学术语、算法名称、设计模式名称、数学名词 等软件编程相关名词。这样似乎有点异端，但这总好过让程序员费劲找客户弄清楚自己原 本清楚的概念，只是由于名称的不同使他们疑惑。我们是讲编码规范，程序员大多数是计 算机专业的，或对计算机专业已有了深入了解的。很少最终用户会阅读程序，即使有，也 是有相当计算机软件功底的。相反，程序维护人员必须阅读程序，所以应尽可能使用计算 机术语。如：运用工厂模式类的命名应该是“名词+Factory” 。 2.1.92.1.9必要时可使用业务术语必要时可使用业务术语 如果工作的重点不

12、在程序本身，或问题的描述比问题的解决更重要，可使用业务术语。 在分析阶段，使用业务术语比使用计算机术语更好，因为容易被客户理解和接受。 2.1.102.1.10避免误导避免误导 避免使用已有其它明确意义的名词。例如，“hp“, “aix“, 和 “sco“ 被用作 UNIX 平 台及其变种的名称，如果再用来作为变量或函数名称就很有问题，会引起误解。即使你在 解决的问题用 “hp“ 是很好的缩写也不应使用“hp“。 2.1.112.1.11名词需要语境说明名词需要语境说明 只有少数情况下，孤立的一个名字有明确含义。多数情况下，名称需要置于一定的语 境中才有意义。比如，在类中，函数中或注释中。换句

13、话说，在面向对象的语言中，在类 属性的名称中包含类名是多余的。例如，不应该使用 Book.BookTitle，而应该使用 . . . . 参考.资料 Book.Title 。Company. address_ 和 Customer. address_， 同样都是 address, 但仅在 语境中才有意义，以下的命名是不可取的：Company. companyAddress_, Customer.customerAddress_。 2.1.122.1.12不要添加人为的语境不要添加人为的语境 不要在类的前面冠以公司名缩写、项目名称缩写或其他标志性前缀。例如，在做知识 管理系统时，把员工类命名成

14、KmsUser。以上命名法是不可取的，这样势必造成代码重复， 影响代码的重用。如使用同一个类，则 KmsUser 在其他系统中就显得不和谐了。 2.1.132.1.13避免名称差别不明显造成混淆避免名称差别不明显造成混淆 这个问题源于编写程序仅仅是为了能编译通过或能解译执行。编译和解译程序不允许 在同一域内用相同的名字指称两个东西。所以，遇到编译问题时，就随便将其中的一个改 变一下。更糟糕的是，原本同一个名称，因拼写错误变成两个名称。这里要说的关键问题 是，如果要区分两样不同的东西，一定要保证名称有实质性的差别。例如，若将一个类命 名成 Product，另一个类命名成 ProductInfo

15、或 ProductData, 就会因差别不明显造成混淆。 因为 Info 和 Data 没有具体的意思。同理，不要在 OO 编程中使用 Class 或 Object 作为 名称的一部分。CustomerObject 和 Customer 有什么区别? NameString 比 Name 好吗? 难道一个 Name 还会是浮点数或整数不成？特别要强调的是，对于大小写敏感的编程环境， 我们不要使用仅有大小写区别的名字。 例如，Customer, customer 不应作为两个名字。 2.22.2 大写风格大写风格 以下章节描述了不同方式的大写方式.这些术语将在通篇文档中被经常引用. 2.2.12.

16、2.1PascalPascal 风格风格 这种风格大写每个单词的首字母 BackColor 应在所有由多单词组成的公共描述符中使用这种方式.举例而言,使用 TextColor 就比 Textcolor 或 Text_color 更好. . . . . 参考.资料 注意不要大写 “连接词”（一个单词中包含了几个单词，但这个单词本身有自己的意 思，如 Checkbook）每个组合单词的首字母。应该将这个单词作为一个单词来考虑，而非 几个单词的组合。使用词典决定一个组合词是不是应该作为一个单词来使用。 2.2.22.2.2CamelCamel 风格风格 这种风格除了第一个单词的首字母,其他单词都应大写首字母,如下所示 backColor 在