DotNet编程规范（草）part3

4异常处理

1.         只捕获经过显示处理的异常。

2.         只捕捉特定的异常，而不是一般的异常。

3.         catch语句中只抛出Exception异常。

4.         发生异常时，给出友好的消息给用户，精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。

5.         不要捕捉了异常却什么也不做。

6.         不必在所有方法中捕捉一般异常。程序崩溃，将帮助你在开发周期发现大多数的错误。

7.         别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。 这将帮你找出哪一段代码产生异常，并给用户发出特定的错误消息。

8.         定义自己的异常时，一定要从Exception继承，并定义自己的序列化 

5可测试性

1.         使用应用程序的日志和跟踪。对程序的运行状态进行记录，结果可保存到文件。（日志格式和方法需要讨论）

2.         检查函数参数合法性。

3.         在使用引用对象之前进行非空判断。

4.         避免让函数返回错误代码。错误码可有全局变量定义。

5.         对代码使用断言。一般说来，每5行应该有一个断言。（这个指标有待讨论）

6项目设置和结构

1.         使用4级警告编译生成工程。（各个级别到底是怎么回事？）

2.         在发布版本中将告警当作错误来处理，调试版本也建议如此。

3.         不要禁用编译告警。

4.         在配置文件中显示的声明运行时版本：

<?xml version = “1.0”?>

<Configuration>

<Startup>

    <SupportedRuntime version = “v2.0.50727.0”/>

   <SupportedRuntime version = “v1.1.4322.0”>

</Startup>

</Configuration>

5.         避免显式地自定义版本改向和绑定到CLR程序集。

6.         不要自己处理预定义#define，使用工程的设置来处理条件编译选项。

7.         不要再AssemblyInfo.cs中添加任何业务逻辑。

8.         程序集的属性信息只能放在AssemblyInfo.cs文件中。

9.         同一个解决方案中要使用相对路径来引用程序集。

10.     禁止在程序集之间的循环引用。

11.     避免生成多模块的程序集。一个程序集只包含一个模块。

12.     AssemblyInfo.cs文件中尽可能包含相关信息，如：公司名称，产权保护等等。

13.     禁止使用Exception窗口（Debugger/Exception）篡改异常处理。

14.     在同一解决方案中的各个程序集，客户端使用相同的版本号。

15.     把解决方案一级的信息放到全局共享的SolutionInfo.cs中。

16.     修改vs2005的默认工程结构以符合公司的情况，并在工程目录和文件中使用统一结构设置。

17.     将发布版本的工程生成设置成包含调试符号。

18.     对程序集进行签名。

19.     把应用程序的配置文件命名为App.config，并包含在工程中。

20.     使用密码保护的键。

21.     总是使用项目的SNK文件对互操作程序集签名。