C#编码规范.doc

C#编码规范版 本 号：3.013变 更 记 录序号修改原因修改目的修改内容修改人/日期审批人/日期修改后的版本号实施日期目 录1.目的32.名词解释与定义33.C#编码规范描述33.1程序结构要求33.2可读性要求33.3代码风格43.4大小写43.5缩写53.6命名规范53.7注释103.8异常处理124.过程应用指南134.1剪裁134.2使用指南135.相关模板131. 目的1. 规范项目代码的编写，保证代码的易维护性和风格的一致性；2. 规范代码评审制度；3. 通过严格合理的单元测试和集成测试保证编码的可靠性和系统的稳定性和准确性。2. 名词解释与定义Pascal 大小写：将标识符的首字母和后面连接的每个单词的首字母都大写。如BackColorCamel 大小写：标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如backColor。匈牙利语表示法：它是一种命名约定，把变量的类型（或者它的预期使用）等信息编码在变量名中。3. C#编码规范描述3.1程序结构要求 1. 程序结构清晰，简单易懂，单个函数的程序行数不得超过 100行。 2. 尽量使用.NET库函数和公共函数(无特殊情况不要使用外部方法调用windows的核心动态链接库)。 3. 不要随意定义全局变量，尽量使用局部变量。3.2可读性要求 1. 读性第一，效率第二(代码是给人读的 .)。 2. 保持注释与代码完全一致。 3. 每个源程序文件，都有文件头说明，说明规格见规范。 4. 每个函数，都有函数头说明，说明规格见规范。 5. 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。 6. 处理过程的每个阶段都有相关注释说明。 7. 在典型算法前都有注释, 同时算法在满足要求的情况下尽可能简单。 8. 利用缩进来显示程序的逻辑结构，缩进量一致并以 Tab键为单位，定义 Tab为 6个字节。 9. 循环、分支层次不要超过五层。 10. 注释可以与语句在同一行，也可以在上行。 11. 空行和空白字符也是一种特殊注释。 12. 一目了然的语句不加注释。 13. 注释的作用范围可以为：定义、引用、条件分支以及一段代码。 14. 注释行数（不包括程序头和函数头说明部份）应占总行数的 1/5 到 1/3.3.3代码风格1. 所有的缩进为4个空格，使用VS.NET的默认设置；2. 为了防止在阅读代码时不得不滚动源代码编辑器，每行代码或注释在1024*768的显示频率下不得超过一显示屏，超过时注意换行；3. 将大的复杂代码节分为较小的、易于理解的模块，运用面向对象的设计思想合理划分模块粒度；4. 编写 SQL 语句时，除了数据内容，对于其他都使用全部大写，包括关键字和数据库对象（如表、列、函数、过程和视图等）； 5. 使用DataSet对象时，表名和列名用有意义的变量，不用无意义的数字3.4大小写1. 不要使用要求区分大小写的名称。对于区分大小写和不区分大小写的语言，组件都必须完全可以使用。不区分大小写的语言无法区分同一上下文中仅大小写不同的两个名称。因此，在创建的组件或类中必须避免这种情况。 2. 不要创建仅是名称大小写有区别的两个命名空间。例如，不区分大小写的语言无法区分以下两个命名空间声明。 namespace ee.cummings;namespace Ee.Cummings;3. 不要创建具有仅是大小写有区别的参数名称的函数。下面的示例是不正确的。void MyFunction(string a, string A)4. 不要创建具有仅是大小写有区别的类型名称的命名空间。在下面的示例中，Point p 和 POINT p 是不适当的类型名称，原因是它们仅在大小写方面有区别System.Windows.Forms.Point pSystem.Windows.Forms.POINT p5. 不要创建具有仅是大小写有区别的属性名称的类型。在下面的示例中，int Color 和 int COLOR 是不适当的属性名称，原因是它们仅在大小写方面有区别。6. 总之，不要定义和使用仅大小写有区别的变量，参数，名称等内容3.5缩写为了避免混淆和保证跨语言交互操作，请遵循有关区缩写的使用的下列规则：1. 不要将缩写或缩略形式用作标识符名称的组成部分。例如，使用 GetWindow，而不要使用 GetWin。 2. 不要使用计算机领域中未被普遍接受的缩写。 3. 在适当的时候，使用众所周知的缩写替换冗长的词组名称。例如，用 UI 作为 User Interface 的缩写，用 OLAP 作为 On-line Analytical Processing 的缩写。 4. 在使用缩写时，对于超过两个字符长度的缩写，请使用 Pascal 大小写或 Camel 大小写。例如，使用 HtmlButton 或 htmlButton。但是，应当大写仅有两个字符的缩写，如，System.IO，而不是 System.Io。3.6命名规范3.6.1类命名规范1. 使用名词或名词短语命名类，体现类的作用。 2. 使用 Pascal 大小写。 3. 少用缩写。 4. 当类是一个异常（Exception）时，以Exception结尾：class ColorSetException；当类只需有一个对象实例（全局对象，比如Application等），必须以class结尾； 例：class SystemClass5. 当类只用于作为其他类的基类，根据情况，以Base结尾： 例：class IndicatorBase6. 如果定义的类是一个窗体，那么名字的后面必须加后缀Form，如果是Web窗体，必须加后缀Page：例：class PrintForm : Inherits Form * Windows窗体class StartPage : Inherits Page * Web窗7. 不要使用类型前缀，如在类名称上对类使用 C 前缀。例如，使用类名称 FileStream，而不是 CFileStream。 8. 有时候需要提供以字母 I 开始的类名称，虽然该类不是接口。只要 I 是作为类名称组成部分的整个单词的第一个字母，这便是适当的。例如，类名称 IdentityStore 就是适当的。 9. 在适当的地方，使用复合单词命名派生的类。派生类名称的第二个部分应当是基类的名称。例如，ApplicationException 对于从名为 Exception 的类派生的类是适当的名称，原因是 ApplicationException 是一种 Exception。请在应用该规则时进行合理的判断。例如，Button 对于从 Control 派生的类是适当的名称。尽管按钮是一种控件，但是将 Control 作为类名称的一部分将使名称不必要地加长。 10. 缩进用TAB键，不用SPACES键。注释需要和代码对齐。花括弧（ ）需和括号外的代码对齐。用一空行来分开代码的逻辑分组。3.6.2接口命名规范1. 用名词或名词短语，或者描述行为的形容词命名接口。例如，接口名称 IComponent 使用描述性名词。接口名称 ICustomAttributeProvider 使用名词短语。名称 IPersistable 使用形容词。 2. 使用 Pascal 大小写。 3. 少用缩写。 4. 给接口名称加上字母 I 前缀，以指示该类型为接口。 3.6.3属性命名规范1. 使用名词或名词短语命名属性。 2. 使用 Pascal 大小写。 3. 不要使用匈牙利语表示法。3.6.4方法命名规范1. 使用动词或动词短语命名方法。 2. 使用 Pascal 大小写。 例如RemovelAll()，GetCharArray()3.6.5事件命名规范1. 使用 Pascal 大小写。 2. 不要使用匈牙利语表示法。 3. 对事件处理程序名称使用 EventHandler 后缀。 4. 指定两个名为 sender 和 e 的参数。sender 参数表示引发事件的对象。sender 参数始终是 object 类型的，即使在可以使用更为特定的类型时也如此。与事件相关联的状态封装在名为 e 的事件类的实例中。对 e 参数类型使用适当而特定的事件类。 5. 用 EventArgs 后缀命名事件参数类。 6. 考虑用动词命名事件。例如，命名正确的事件名称包括 Clicked、Painting 和 DroppedDown。 7. 使用动名词（动词的“ing”形式）创建表示事件前的概念的事件名称，用过去式表示事件后。例如，可以取消的 Close 事件应当具有 Closing 事件和 Closed 事件。不要使用 BeforeXxx/AfterXxx 命名模式。 8. 不要在类型的事件声明上使用前缀或者后缀。例如，使用 Close，而不要使用 OnClose。 9. 通常情况下，对于可以在派生类中重写的事件，应在类型上提供一个受保护的方法（称为 OnXxx）。此方法只应具有事件参数 e，因为发送方总是类型的实例。3.6.6参数和临时变量命名规范1. 名称使用 Camel 大小写。如：string userName;public AddUser(string userName, byte password);2. 使用描述性名称。名称应当具有足够的描述性，以便参数或临时变量的名称及其类型可用于在大多数情况下确定它的含义。3. 使用描述含义的名称，而不要使用描述类型的名称。少用基于类型的名称，仅在适合使用它们的地方使用它们。 4. 不要使用保留的参数。保留的参数是专用参数，如果需要，可以在未来的版本中公开它们。相反，如果在类库的未来版本中需要更多的数据，请为方法添加新的重载。 5. 不要给参数或临时变量名称加匈牙利语表示法的前缀。3.6.7静态字段命名规范1. 使用名词、名词短语或者名词的缩写命名静态字段。 2. 使用 Pascal 大小写。 3. 不要在静态字段名称中使用匈牙利语表示法的前缀。 4. 建议尽可能使用静态属性而不是公共静态字段。3.6.8枚举类型命名规范1. 对于 Enum 类型和值名称使用 Pascal 大小写。 2. 少用缩写。 3. 不要在 Enum 类型名称上使用 Enum 后缀。 4. 对大多数 Enum 类型使用单数名称，但是对作为位域的 Enum 类型使用复数名称。 3.6.9结构命名规范必须以名词或名词短语命名，最好体现结构的特点。例如：structure CustomerInfoRecord。3.6.10控件命名规范控件命名 = 控件的类型（为了减少输入量考虑缩写）+ 变量名控件名称缩写范例adrotatoradrtadrtTopadButtonbtnbtnSubmitCalendarcalcalMeetingDatesCheckBoxchkchkBlueCheckBoxListchklchkFavcolorsComboBoxcbcbValueCompareValidatorvalcvalcValidAgeCustomValidatorvalxvalxDbcheckDataGriddgrddgrdTitlesDataListdlstdlstTiltlesDropDownListddltHyperlinklinklnkDetailsImageimgimgAuntBettyImageButtonIbtnibtnSubmitLabellbllblResultsLinkButtonlbtnListBoxlstPanelpnlRadioButtonradRadopButtonListradlRangeValidatorvalgRegularexpressionvaleRepeaterrptRequiredFieldValidatorvalrTabletblTableCelltblcTableRowtblrTextBoxtxtTreeViewtvtvNodeValidationsummaryvalsXmlxmlcTreeviewtreeMenuItemmimiCloseMainmenumenuContextM控件名称缩写范例connctionconconNorthwind(con +数据库名称)commandcmdcmdReturnProductsParameterparmparmProductIdDataAdapterdaddadProductsDataReaderdtrdtrProductsDataSetdstdstNorthwindDataTabledtbldtblPrpductsDataRowdrowdrowRow98DataColumndcoldcolProductIdDataRelationdreldrelMasterDetarilDataviewdvwdvwfilteredProducts 3.6.11命名空间命名规范1. 命名命名空间时的一般性规则是使用公司名称，后跟技术名称和可选的功能与设计，如下所示：CompanyName.TechnologyName.Feature.Design例如：Microsoft.MediaArk.Frameworks.Data2. 给命名空间名称加上公司名称或者其他知名商标的前缀可以避免两个已经发布的命名空间名称相同的可能性。例如，Microsoft.Office 是由 Microsoft 提供的 Office Automation Classes 的一个适当的前缀。3. 应当对命名空间使用 Pascal 大小写，并用句点分隔逻辑组件，如 Microsoft.Office.PowerPoint 中所示。如果您的商标使用非传统的大小写，请遵循您的商标所定义的大小写，即使它与规定的 Pascal 大小写相背离。例如，命名空间 NeXT.WebObjects 和 ee.cummings 阐释了对于 Pascal 大小写规则的适当背离。4. 不要为命名空间和类使用相同的名称。例如，不要既提供 Debug 命名空间也提供 Debug 类。5. 最后，请注意命名空间名称不必非得与程序集名称相似。例如，如果命名程序集 MyCompany.MyTechnology.dll，它没有必要非得包含 MyCompany.MyTechnology 命名空间。6. 在使用过程中尽量在程序文件的开始引入命名空间，使用过程中直接使用类名称例如：using Ark.Dras2005.Entity.Mas;使用时候直接定义该命名空间下的类MasClass 这样声明MasClass cls；不建议这样声明Ark.Dras2005.Entity.Mas.MasClass cls；3.7注释3.7.1基本原则1、修改代码时，总是使代码周围的注释保持最新。2、在每个例程的开始，提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍。3、避免在代码行的末尾添加注释；行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释在公共制表位处对齐。 4 、避免杂乱的注释，如一整行星号。而是应该使用空白将注释同代码分开。 5 、避免在块注释的周围加上印刷框。这样看起来可能很漂亮，但是难于维护。6 、在部署发布之前，移除所有临时或无关的注释，以避免在日后的维护工作中产生混乱。7 、如果需要用注释来解释复杂的代码节，请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码，而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能，但必须保持性能和可维护性之间的平衡。8 、在编写注释时使用完整的句子。注释应该阐明代码，而不应该增加多义性。 9 、在编写代码时就注释，因为以后很可能没有时间这样做。另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。10 、避免多余的或不适当的注释，如幽默的不必要的备注。11、 使用注释来解释代码的意图。它们不应作为代码的联机翻译。 12、 注释代码中不十分明显的任何内容。13 、为了防止问题反复出现，对错误修复和解决方法代码总是使用注释，尤其是在团队环境中。14 、对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。 15 、在整个应用程序中，使用具有一致的标点和结构的统一样式来构造注释。 16 、用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时，这样做会使注释很明显且容易被找到。17 、在所有的代码修改处加上修改标识的注释。18 、为了是层次清晰，在闭合的右花括号后注释该闭合所对应的起点。 namespace Langchao.Procument.Web / namespace Langchao.Procument.Web3.7.2文档型注释该类注释采用.Net已定义好的Xml标签来标记，在声明接口、类、方法、属性、字段都应该使用该类注释，以便代码完成后直接生成代码文档，让别人更好的了解代码的实现和接口。如：/MyMethod is a method in the MyClass class./Heres how you could make a second paragraph in a description./ /for information about output statements./ / /