U9 编码规范 导言 1.1、 目的 该文档旨在提高 U9 开发人员代码编写的一致性，使开发人员在代码级别有统一的规范和认识，便于开发人员在代码级的交流，从而提高代码质量。为达到该目地，该文档提出一些指导性的原则，在 Code Review 阶段该文档也将作为代码标准规范的参考资料。 该文档主要目的： 1、 避免由于代码规范而引入的 bug 和错误。 2、 避免有明显效率问题的代码。 3、 提高代码的可维护性。 4、 统一编码风格。 该文档主要包括 C#编码规范，并且对 U9 的性能规范做了引用，有关 UBF 的编程规范请参考《UBF 编程规范》。该规范参考了网络上目前流行的并且已经经过验证的编码规则，其中大部分引用了微软的《C++ Code Standard》，以及 MSDN 的相关内容。 按类型以及 U9 的实际情况划分，文档分为四大部分：命名规范、代码风格、专项主题以及 WCF 编码规范。其中命名规范主要描述 U9 开发人员在实际的工作开发中对源代码中各种标识符的命名约束，此部分内容将给你大部分的命名建议以及推荐的做法。代码风格主要描述代码应该如何布局，注释如何布局以及其他一些有关代码布局的相关信息，专项内容为可扩充内容，读者可参考阅读，WCF 部分还在整理阶段。 1.2、 范围 该文档只描述 C#编码规范的相关内容以及代码布局的规范问题，该文档并不描述.NET 相关类库的内容和使用，也不描述 C#编程语言。 该文档适用于：U9 所有从事代码开发工作的人员。 1.3、 文档约束 为了保证文档的严格性和一致性，下面对文档中出现的字体颜色和标识做统一说明。 蓝色字体：标识 C#的关键字或者.NET 的通用类型。 加粗字体：标识重点内容，此部分内容读者在阅读的时候需要特别注意。 绿色字体：标识为代码注释。 … ：标识为省略的部分，根据上下文的不同省略的部分会有不同。 斜体字 ：标识为需要参考的资料。 根据不同的条目，本文档会给出两种不同的例子，我称之为：不推荐和推荐。不推荐的做法是您在编码的时候应该极力避免的，推荐的做法是您在编码是我所提倡的使用方法。 1.4、 历史记录 版本 修改原因 时间 概述 修改人 审阅人 1.0 beta 创建原始文档 2008-6-10U9 编码规范吴剑 1.0 分类排版 2008-6-28添 加 一 些 新内容 吴剑 术语描述和定义 为了在理解上和读者达成一致，下面对文档中出现的术语和定义做详细的描述。该部分内容为可变的，根据版本的迭代会引入更多的术语和定义。 可访问性 C#中类型和他们的成员包括 4 种访问级别，它们分别是 public,private,protected,internal。除了接口和枚举以外其他的默认访问级别都是private，接口和枚举的默认访问级别是public。 Camel Case 这是一种命名方案，它描述了标识符第一个单词的首字母小写，除第一个单词外所有的单词首字母必须大写的一种命名方案。 例如：exampleWordList Pascal Case 这是一种命名方案，它描述了标识符的所有单词的首字母必须大写。 例如：ExampleWordList Common Type System 由于类型是 CLR 的根基，为此微软制定的一个标准的规范—CTS， CTS 描述了类型如何声明和使用，CTS 规范保证了.NET 的跨语言整合。 GAC 全局程序集缓存，这里存放的都是强命名的程序集，动态装载这里的程序集将不会出现dll 映射的内存泄漏问题，详细信息请参考《U9 效率规范》。 GC 垃圾收集器，垃圾收集器是.NET 的核心功能之一，它可以回收托管内存中的垃圾对象，它掌管着所有的托管对象的生命周期，有关垃圾收集的详细信息请参考 MSDN。 CLR 公共语言运行时，它提供了.NET 程序的运行平台，托管对象的分配与回收等。 我们 文章中出现的我们和我通常指 ISV 小组。 通用规则 � 任何时候都必须遵照本规范的建议执行，除非你有更好或者特殊的理由，如果有请将它反馈给我们，我们将根据您的建议修改该文档，或者给您修改建议。 � 任何时候都不要将一些不相干的代码放到一个文件里，代码应该按照逻辑来组织保存在文件中。 � 任何时候不要在一个文件里面写超过一个以上的类。虽然 C#允许您可以这么做，...
