软件开发代码规范

软件开发代码规范（C#版）

拟制:日期：2007-2-13审核:日期：

审核:日期：

批准:日期：

版权所有 ********有限公司

修订纪录

目录

1、第一章命名规范...................................... 错误!未定义书签。、第一节总则............................................. 错误!未定义书签。、第二节变量命名规范...................................... 错误!未定义书签。

、CodeBehind内部命名规范............................ 错误!未定义书签。

、控件命名规范....................................... 错误!未定义书签。、第三节常量命名规范..................................... 错误!未定义书签。、第四节命名空间、类、方法命名规范....................... 错误!未定义书签。、第五节接口命名规范..................................... 错误!未定义书签。、第六节命名规范小结................................. 错误!未定义书签。

2、第二章代码注释规范....................................... 错误!未定义书签。、第一节模块级注释规范（命名空间、类等）................. 错误!未定义书签。、第二节方法级注释规范................................... 错误!未定义书签。

、属性注释.......................................... 错误!未定义书签。

、方法注释.......................................... 错误!未定义书签。、第三节代码间注释规范................................... 错误!未定义书签。

3、第三章编写规范.......................................... 错误!未定义书签。、第一节格式规范.......................................... 错误!未定义书签。、第二节编程规范.......................................... 错误!未定义书签。

、程序结构要求...................................... 错误!未定义书签。

、可读性要求........................................ 错误!未定义书签。

、结构化要求........................................ 错误!未定义书签。

、正确性与容错性要求................................ 错误!未定义书签。

、可重用性要求...................................... 错误!未定义书签。

、interface使用注意事项............................ 错误!未定义书签。

、类使用注意事项.................................... 错误!未定义书签。

、流程控制语句注意事项.............................. 错误!未定义书签。

、其他应注意事项.................................... 错误!未定义书签。

注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用小写形式。

Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。

1、第一章命名规范

1.1、第一节总则

1．本命名规则除特殊提及外统一使用Camel命名法则。

如：controlMenu

2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。

3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。

如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX

4．使用专有名词或英文缩写命名时采用大写形式。

如：CNNIC

5．禁止使用仅区分大小写的方式命名。

如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移

、第二节变量命名规范

1.2.1、CodeBehind内部命名规范

1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。

例：

public class Hello

{

private string userName;

private DateTime loginTime;

private bool isOnline;

public string UserName {

get { return ; }

}

}

2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j

3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。

4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。

例：

string str Name;

int int Age;

object obj Person;

1.2.2、控件命名规范

1．控件命名使用控件缩写加名称的方式

、第三节常量命名规范

常量名也应当有一定的意义，格式为 NOUN 或 NOUN_VERB。常量名均为大写，字之间用下划线分隔。

例：

private const bool WEB_ENABLEPAGECACHE_DEFAULT = true;

private const int WEB_PAGECACHEEXPIRESINSECONDS_DEFAULT = 3600;

private const bool WEB_ENABLESSL_DEFAULT = false;

注：

变量名和常量名最多可以包含 255 个字符，但是，超过 25 到 30 个字符的名称比较笨拙。此外，要想取一个有实际意义的名称，清楚地表达变量或常量的用途，25 或 30 个字符应当足够了。

、第四节命名空间、类、方法命名规范

1．名字应该能够标识事物的特性。

2．名字尽量不使用缩写，除非它是众所周知的。

3．名字可以有两个或三个单词组成，但通常不应多于三个。

4．使用名词或名词短语命名类。

5．尽可能少用缩写。

6．不要使用下划线字符 (_)。

7．命名空间名称使用此格式：Snda + 项目名称 + 逻辑层名称

例：

namespace class FileStream

{

public void InPut(string para)

{}

}

}

、第五节接口命名规范

和类命名规范相同，唯一区别是接口在名字前加上大写“I”前缀

例：

interface IDBCommand;

interface IButton;

、第六节命名规范小结

1、使用Pascal命名方式命名类、方法、属性和常量

2、使用Camel命名方式命名局部变量和方法的参数

3、接口使用Pascal命名方式，并且在前面添加“I”

4、方法命名使用动宾结构，比如ShowDialog( )

5、有返回值的方法命名应有单词来描述，比如GetObjectState( )

6、避免使用带命名空间的类型，尽量用using关键字

7、避免把using语句放到命名空间内

8、控件命名使用控件缩写加名称的方式

9、常量命名采用全部大写的形式，要想一个有实际意义的名称，清楚地表达常量的用途2、第二章代码注释规范

、第一节模块级注释规范（命名空间、类等）

模块须以以下形式书写模块注释：

1． 2.2.12.2.2Para3.2.1ET库函数和公共函数(无特殊情况不要使用外部方法调用Windows的核心动态链接库API)。

2．不要随意定义全局变量，尽量使用局部变量。

3.2.2 、可读性要求

1．保持注释与代码完全一致。

2．去除无效的注释

3．处理过程的每个阶段都有相关注释说明。

4．利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为 4个空格。

5．循环、分支层次不要超过五层。

6．注释可以与语句在同一行，也可以在上行，视语句的长短而定。

7．一目了然的语句不加注释。

8．注释的作用范围可以为：定义、引用、条件分支以及一段代码。

9．去除IDE自动生成的注释，比如：

...

private void Page_Load(object sender, EventArgs e) {

.（删除这段注释）

}

3.2.3 、结构化要求

1．禁止出现两条等价的支路。

2．除了在switch关键字的作用域内，禁止goto语句。

3．用 if 语句来强调只执行两组语句中的一组。禁止 else goto 和 else return。

4．用 case实现多路分支。

5．避免从循环引出多个出口。

6．函数只有一个出口。

7．尽量不使用条件赋值语句。

8．避免不必要的分支。

9．不要轻易用条件分支去替换逻辑表达式。

3.2.4 、正确性与容错性要求

1．程序首先是正确，其次是优美。

2．无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。

3．改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。

4．所有变量在调用前必须被初始化。

5．对所有的用户输入，必须进行合法性检查。

6．尽量不要比较浮点数的相等，

如： * == ，不可靠，因为不同CPU的浮点运算能力是不同的7．程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑

锁定、打印机是否联机等,对于明确的错误,要有明确的容错代码提示用户，在这样不确定的场合都使用try throw catch。

8．单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。

9．尽量使用规范的容错语句.

例：

try

{}

catch

{}

finally

{}

3.2.5 、可重用性要求

1．重复使用的完成相对独立功能的算法或代码应抽象为服务或类。

2．服务或类应考虑OO思想，减少外界联系，考虑独立性或封装性。

3.2.6 、interface使用注意事项

1．避免一个接口中只有一个成员。尽量使每个接口中包含3－5个成员。接口中的成员不应该超过20个。避免接口成员中包含事件。

2．推荐使用显式的接口实现。

3.2.7 、类使用注意事项

1．避免方法的返回值是错误代码。

2．尽量定义自定义异常类。当需要定义自定义的异常时：

a) 自定义异常要继承于ApplicationException。

b) 提供自定义的序列化功能。

3．只对外公布必要的操作。

4．使程序集尽量为最小化代码(EXE客户程序)。使用类库来替换包含的商务逻辑。

5．不要提供public的成员变量，使用属性代替他们。

6．避免在继承中使用new而使用override替换。

7．在不是sealed的类中总是将public 和 protected的方法标记成virtual的。

8．避免显式的转换，使用as操作符进行兼容类型的转换。

例：

Dog dog = new GermanShepherd();

GermanShepherd shepherd = dog as GermanShepherd;

if (shepherd != null )

{…}

9．当类成员包括委托的时候在调用委托之前一定要检查它是否为null

例：

public class MySource

{

public event EventHandler MyEvent;

public void FireEvent()

{

EventHandler temp = MyEvent;

if(temp != null )

{

temp(this,;

}

}

}

10．不要提供公共的事件成员变量，使用事件访问器替换这些变量。

例：

public class MySource

{

MyDelegate m_SomeEvent ;

public event MyDelegate SomeEvent

{

add

{

m_SomeEvent += value;

}

remove

{

m_SomeEvent -= value;

}

}

}

11．避免在结构里面提供方法。建议使用参数化构造函数，可以重裁操作符。

12．类成员间调用请尽量使用this关键字。

13．除非你想重写子类中存在名称冲突的成员或者调用基类的构造函数否则不要使用base来访问基类的成员。

3.2.8 、流程控制语句注意事项

1．即使if语句只有一句，也要将if语句的内容用大括号扩起来。

2．避免在条件语句中调用返回bool值的函数。可以使用局部变量并检查这些局部变量。

例：

bool IsEverythingOK()

{…}

//避免

if (IsEverythingOK ())

{…}

//替换方案

bool ok = IsEverythingOK();

if (ok)

{…}

3．总是使用基于零开始的数组。

4．在循环中总是显式的初始化引用类型的数组。

例：

public class MyClass

{}

MyClass[] array = new MyClass[100];

for(int index = 0; index < ; index++)

{

array[index] = new MyClass();

}

5．除非在不完全的switch语句中否则不要使用goto语句。

3.2.8 、其他应注意事项

1．避免将多个类放在一个文件里面。

2．一个文件应该只有一个命名空间，避免将多个命名空间放在同一个文件里面。

3．一个文件最好不要超过500行的代码（不包括机器产生的代码）。

4．避免方法中有超过5个参数的情况。使用结构来传递多个参数。

5．每行代码不要超过80个字符。

6．不要手工的修改机器产生的代码。如果需要编辑机器产生的代码，编辑格式和风格要符合该编码标准。

7．不要硬编码数字的值，总是使用构造函数设定其值或采用常数的方式。

8．只有是自然结构才能直接使用const，比如一个星期的天数。

9．避免在只读的变量上使用const。如果想实现只读，可以直接使用readonly。

例：

public class MyClass

{

public readonly int Number;

public MyClass(int someValue)

{

Number = someValue;

}

public const int DAYS_IN_WEEK = 7;

}

10．代码的每一行都应该通过白盒方式的测试。

11．在捕获(catch)语句的抛出异常子句中(throw)，总是抛出原始异常维护原始错误的堆栈分配。

例：

catch(Exception exception)

{

;

throw; //和throw exception一样。

}

12．避免在单个程序集里使用多个Main方法。

13．数据访问中凡是使用DateReader对象的，必须使用using语句来即时释放资源；对于Stream、StreamReader之类的对象，也要使用using语句来即时释放资源14．避免指定特殊类型的枚举变量。

例：

//避免

public enum Color : long

{

Red,Green,Blue

}

15．不要硬编码可能更改的基于配置的字符串，比如连接字符串。

16．当需要构建长的字符串的时候，使用StringBuilder不要使用string

17．能使用早期绑定就不要使用后期绑定。

18．使用应用程序的日志和跟踪。

19．总是选择使用C#内置（一般的generics）的数据结构。比如：使用int 而不用 Int32,使用object 而不用Object，使用string 而不用 String 等。

20．将所有的系统命名空间组织在一起，将所有自定义的命名空间组织在一起例：

using System;

using ;

using ;

using MyNameSpace;

using MyControls;

21．数据访问方法编写完成之后，必须进行单元测试，保证调用无异常。

22．使用一个对象（或对象的属性）前，必须保证该对象非空(作null 判断)。23．使用一个数组中的某个元素时，必须保证不会超出索引界限。

24．开发中，对于Repeater、DataList、GridView一类的服务器控件。应本着节约服务器资源的原则，能用DataList完成的就不用GridView，能用Repeater完成的就不用DataList。

25．开发中，对于页面上服务器端控件产生的ViewState，没实际用处的就直接禁用；对于首页、频道页等会被缓存的页面，要慎重使用服务器端控件，不允许产生任何

ViewState，并且不要使用postback提交

26．开发中，对于页面上服务器端控件产生的ViewState，没实际用处的就直接禁用；对于首页、频道页等会被缓存的页面，要慎重使用服务器端控件，不要使用postback 提交，不允许产生任何ViewState

27．对于数据访问层、业务层和页面层抛出的异常，要区分出Exception和Error，对这两种情况进行区分处理。Exception一般指数据库的、非控的严重错误，务必要记录下异常类型以及堆栈信息，以便将来排查问题；对于Error通常都是指业务错误，此时需要记录下发生错误的相关参数和errorcode以便重现问题即可。

28． WEB页面开发完成后，要作浏览器兼容性测试（IE6、FF最新版、google浏览器）28．下班前要确保工程里的所有文件处于签入状态（对于已经开发完成并测试通过的功能可以直接签入；对于尚未开发完成或者尚未经QA确认的功能则先注释掉相关修改，再行签入）