.NET环境下我的的编码准则
1.1 命名规则
1.1.1 数据库元素命名规则
名称全部采用小写字母。
|
类型 |
前缀 |
举例 |
说明 |
|
表单 |
T |
t_bi_city |
|
|
视图 |
V |
v_bi_city |
|
|
存储过程 |
P |
p_bi_city_insert |
|
|
触发器 |
Tg |
tg_bi_city |
|
1.1.2 常用控件命名规则
|
类型 |
前缀 |
例子 |
说明 |
|
TextBox |
Txt |
tbx_custNo |
|
|
CheckBox |
Chk |
cbx_yN |
|
|
Button |
Btn |
btn_ok |
|
|
ComboBox |
Cmb |
cbx_department |
|
|
ListBox |
Lst |
lbx_students |
|
|
ImageButton |
Ibt |
ibt_confirm |
|
|
DataGrid |
Dgd |
dgd_dataQuery |
|
1.1.3 函数命名规则
具有意义的英文单词组合，每个单词的首字母大写。
如：HasOprRight ()（表示是检查用户是否有某项操作的权限）
1.1.4 常量命名规则
全部采用大写字母。
1.1.5 变量命名规则
为了便于代码阅读，查找错误，变量命名可采用下表的命名规则：
|
类型 |
前缀 |
举例 |
说明 |
|
Int |
I |
i_totalCount |
|
|
String |
S |
s_userName |
|
|
Bool |
B |
b_hasOperateRgt |
|
|
Date |
D |
d_nowDate |
|
1.2 编码规则
1.2.1 代码中SQL语句规则
1 SQL语句中关键字统一用小写；
2 SQL语句中，表名和字段统一采用大写；
3 SQL语句，如果属于通用查询，将SQL语句作为常量存放到公共函数的常量表中。否则也必须存放类头常量变量定义的位置。
如：private const string updateRoleSql = " update T_USR_ROLE_ASS set DATA_RIGHT='{2}' where USR_ID={0} and ROLE_ID={1}";
1.2.2 Session变量规则
1 所有的Session的关键字名程必须在公用模块的常量表定义；
2 在定义Session的时候给出Session的说明；
如：//Session["MultiPageListCont"] ----> 存放多页面对象
3 Session在说明的时候必须说明Session传递范围，如在那个页面，或者在那些模块，或全部范围内使用，并且必须说明在哪些地方清除Session。将清除Session的语句写到公共函数中，方便核对检查。
1.2.3 注释规则
1在需要的地方注释，不要每行代码，每个声明的变量都做注释。
2 对一个数值变量采用不是0,-1等的数值初始化，给出选择该值的理由；
3 对注释做拼写检查，保证语法和标点符号的正确使用。
1.2.4 类的规则
1 一个类的代码不能超过400行。如果一个类的代码超过300～400行，必须考虑将代码分开到不同的类中。
2一个类中不同的方法需以空行隔开。
1.2.5 函数规则
1 一个函数的代码不能超过25行。一个典型的方法代码在1～25行之间。如果一个方法代码超过25行，应该考虑将其分解为不同的方法；
2一个函数只能完成一个任务。即使任务非常小，也别把多个任务组合到一个函数中；
3 必须能从函数的函数名中看出该函数的功能，别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了；
4 花括弧需独立一行，而不象if, for 等可以跟括号在同一行；
5在每个运算符和括号的前后都补一个空格；
6 使用C# 或 VB.NET的特有类型，而不是System命名空间中定义的别名类型。
如好的解决方法是：
int age;
string name;
object contactInfo;
不妥当的方法是：
Int16 age;
String name;
Object contactInfo;
7 别在程序中使用固定数值，用常量代替；
8 别用字符串常数。用资源文件；
9 避免使用很多成员变量。声明局部变量，并传递给方法。不要在方法间共享成员变量。如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值；
10 必要时使用enum ，别用数字或字符串来指示离散值。
如好的做法是：
enum MailType
{
Html,
lainText,
ttachment
}
void SendMail (string message, MailType mailType)
{
switch ( mailType )
{
case MailType.Html:
// Do something
break;
case MailType.PlainText:
// Do something
break;
case MailType.Attachment:
// Do something
break;
default:
// Do something
break;
}
}
不妥的做法是：
void SendMail (string message, string mailType)
{
switch ( mailType)
{
case "Html":
// Do something
break;
case "PlainText":
// Do something
break;
case "Attachment":
// Do something
break;
default:
// Do something
break;
}
}
11别把成员变量声明为 public 或 protected。都声明为 private ，用 public/protected 的Properties.
12 不在代码中使用具体的路径和驱动器名。 使用相对路径，并使路径可编程。 永远别设想你的代码是在“C:”盘运行。你不会知道，一些用户在网络或“Z:”盘运行程序。
13应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据库连接。出现任何问题给用户一个友好的提示。
14 如果找不到必须的配置文件，应用程序需要能创建使用默认值的一份。
15 如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。
16 错误消息需要能帮助用户解决问题。永远别用类似于“应用程序出错”、 “发现一个错误” 等错误消息。而应给出类似于 “更新数据库失败。请确保登录ID和密码正确。”的具体消息。显示错误消息时，除了说哪里错了，还应提示用户如何解决问题。不要用类似于“更新数据库失败。”这样的，要提示用户怎么做，如：“更新数据库失败。请确保登录ID和密码正确。”
17显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。
1.2.6 异常处理
1不要“捕捉了异常却什么也不做“。如果隐藏了一个异常，用户将永远不知道异常到底发生了没有。
2发生异常时，给出友好的消息给用户，精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
3只捕捉特定的异常，而不是一般的异常。
如：好的做法是：
void ReadFromFile ( string fileName )
{
try
{
// read from file.
}
catch (FileIOException ex)
{
// log error.
// re-throw exception depending on your case.
throw;
}
}
不好的做法是：
void ReadFromFile ( string fileName )
{
try
{
// read from file.
}
catch (Exception ex)
{
// Catching general exception is bad... we will never know whether it
// was a file error or some other error.
// Here you are hiding an exception.
// In this case no one will ever know that an exception happened.
return "";
}
}
4在开发周期内，不要在所有的方法中都捕捉一般异常。直接让程序抛出异常，这将在开发周期就能发现大多数的错误；
5可以用应用程序级（线程级）错误处理器处理所有一般的异常。遇到“以外的一般性错误”时，此错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或用户选择“忽略并继续”之前记录错误信息；
6不必每个方法都用try-catch。当特定的异常可能发生时才使用。比如，当你写文件时，处理异常FileIOException；
7 try-catch 模块包含内容不能太多。如果需要，为每个执行的任务编写单独的 try-catch 模块。
8如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。
