CodingStandard

编码规范Coding Standard1. 命名和书写规范1) 方法和类型的命名按照Pascal命名规范，即名称中每个字符子串第一个字母大写。

public class S ome C lass{public S ome M ethod(){}}2) 局部变量和方法的参数的命名规范，一般本地变量用m开头；方法参数用a开头；方法体里定义的变量以l开头；int mN umber;void MyMethod(int aS ome N umber){int l Count;}3) 方法的命名采用verb-object（行为－目标）结构（动宾短语），例如：ShowDialog()4) 有返回值的方法的名字应该采用可以描述其意义的名字，例如：GetObjectState()5) 使用描述性的变量名a) 避免使用单字母的变量名，如i，t等，应该采用index 和temp 代替。

（只在循环内使用的局部变量可以使用单字母变量）b) 避免使用匈牙利命名法命名public 和protected 的成员。

c) 尽量避免使用单词的缩写（如用num 代替number）6) 尽量使用c#定义的类型原形而不是用在System 命名空间中重定义的变量名。

用object 而不用Object用string 而不用String用int 而不用Int327) 添加引用应该使用using 替代。

8) 避免在命名空间内部使用using 语句。

9) 把所有使用的命名空间放在一起，并先排framework的命名空间再排自己获第三方的命名空间。

using System;using System.Collections;using ponentModel;using System.Data;using MyCompany;using MyControls;10) 保持精确的缩进a) 使用Tab或其他非标准缩进。

11) 注释的缩进和同级的代码的缩进保持一致。

12) 所有文档的注释都要进行拼写检查，错误的注释拼写会严重影响代码的可读性。

13) 所有的成员变量应该放在顶部，并用一个空行把它与方法和属性分开。

public class MyClass{int m_Number;string m_Name;public void SomeMethod1(){}public void SomeMethod2(){}}14) 局部变量的申明应尽可能与第一次使用它的地方接近。

15) ( { )应该占一个新行并处于开头。

2.注释1) 源程序有效注释量需占源程序20％以上。

注释格式要统一。

2) 避免使用一组图形或者特殊符号做成一个块或者长方形等的注释形式。

这样可能开起来很生动，但是却很难维护。

3) 删除所有暂时的或者无用的注释，从而避免未来维护工作的混淆。

4) 在修改代码的同时，一定要始终保持注释的同步更新。

5) 在每一个程序的最初阶段，有必要提供标准的注释样本，来解释该程序的目的、运行前提条件和相应的限制点。

一个注释样本应该是对于该程序为什么编写，程序主要要完成什么样的功能等，做一个简单的描述。

6)对于行注释，要加在该行的上一行。

用c++风格的双斜线“//”来标识。

对于块注释，加载块的顶部，用c风格的“/* */”来标识。

7)当书写注释的时候，必须使用完整的句子注释应该是使代码含义清晰的，而不是去增加不明确性。

避免那些冗余的或者不合适的注释，比如一些幽默的旁记等等。

使用注释来解释代码的目的，而不是代码的单纯的翻译。

8) 在你编码的时候就书写注释。

因为可能到后来你就没有时间去书写它们了。

而且，如果给你一个机会让你去重新访问你已经写完的代码，可能你对今天刚刚写完的代码非常清楚，但是对于六周之前写的代码可能都已经模糊不清了。

9) 在代码中任何不能明显读懂的地方都要书写注释。

10)说明性文件头部应进行注释，注释必须列出：版本、类名、文件名、作者、完成日期、功能描述、修改历史（修改日期、修改者、修改内容）等，头文件的注释中还应有函数功能简要说明。

11）函数头部应进行注释，列出：函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。

示例：/*************************************************Function: // 函数名称Description: // 函数功能、性能等的描述Calls: // 被本函数调用的函数清单Called By: // 调用本函数的函数清单Table Accessed: // 被访问的表（此项仅对于牵扯到数据库操作的程序）Table Updated: // 被修改的表（此项仅对于牵扯到数据库操作的程序）Input: // 输入参数说明，包括每个参数的作// 用、取值说明及参数间关系。

Output: // 对输出参数的说明。

Return: // 函数返回值的说明Others: // 其它说明*************************************************/注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。

注释与所描述内容进行同样的缩排。

3. 编码实践1) 避免把多个类放在同一个文件中。

2) 一个文件应该只有一个命名空间，避免在同一个文件中有多个命名空间。

3) 为便于查看代码，代码行长度不要超过80个字符。

可以采用分行显示！4) 禁止手工更改编译器产生的代码。

5) 可能的情况下，尽量不要使用原义数字或原义字符串，如For i = 1 To 7。

而是使用命名常数，如For i = 1 To NUM_DAYS_IN_WEEK 以便于维护和理解。

6) 对于只读型的变量，不要采用const 定义为常量而应直接定义为readonly 型。

例如：public class MyClass{public readonly int Number;public MyClass(int someValue){Number = someValue;}public const int DaysInWeek = 7;}7) 在同一个编译单元中避免有多个Main() 。

8) 只有非常有必要的情况下采用public ，否则应采用受保护的关键字。

9) 避免使用friend 关键字，它会增加编译单元之间的耦合程度。

10) 沿逻辑结构行缩进代码。

即便是代码块只有一行代码。

11) 避免使用三操作数的条件表达式12) 避免在条件表达式中直接调用有布尔型返回值的函数，而应该先将其返回值赋给一个本地变量。

例如：bool IsEverythingOK(){…}//Avoid:if(IsEverythingOK()){…}//Instead:bool ok = IsEverythingOK();if(ok){…}13) 尽量使用用零初始化的数组。

14) 在类和接口中，方法和属性的比率应至少为2：1。

15) 避免只有一个成员接口，每个接口尽量保持12个左右的成员，最多不超过20个。

16) 避免将事件作为接口的成员。

17) 避免使用abstract （抽象）方法，应用接口替代。

18) 要直接呈现到用户终端的字符串不要直接编码而应采用资源文件。

（主要是考虑多语言支持，我们目前可不考虑）19) 要因不同环境发生改变的字符串不要直接编码，如数据库的连接字符串。

20) 当使用较长字符串时，用StringBuilder 代替string。

21) 当提供一个静态的成员变量时要提供一个静态的构造函数。

22) 尽量避免使用goto 。

23) 在switch 选择中应定义一个default 选择。

int number = SomeMethod();switch(number){case 1:Trace.WriteLine("Case 1:");break;case 2:Trace.WriteLine("Case 2:");break;default:Debug.Assert(false);break;}24) 除了在一个构造器内调用另一个构造器，否则不要使用this 引用。

//Example of proper use of ’this’public class MyClass{public MyClass(string message){}public MyClass() : this("hello"){}}25) 除了在解决子类与基类成员冲突和调用基类构造函数外避免使用base 关键字。

//Example of proper use of ’base’public class Dog{public Dog(string name){}virtual public void Bark(int howLong){}}public class GermanShepherd : Dog{public GermanShepherd(string name): base(name){}override public void Bark(int howLong){base.Bark(howLong);}}。