以下是本人对
.Net
平台开发实践的一些点滴总结。这里的技术规范主要是开发过程的代码规范、数据库设计规范、
Com
和
.Net
互操作规范；实践精华是对技术实践过程中的部分总结。
良好的代码风格来自于同一的代码规范。风格良好的代码不仅具备可读性和可维护性，同时也给人行云流水、赏心悦目之快感。
据
Microsoft
公司统计，基于微软平台的开发中，有
70-80%
的印度工程师在完成同类算法或者模块时，使用的代码基本一致；而相同的调查中只有
20%
的中国工程师们是基本一致的。这说明我们的代码生产过程亟待规范。
类型、变量、常量、方法等标识符一律采用对应的英文实义；如果涉及到两个独立的实义单词，则中间用下划线间隔或者单词首字母大写（两种方式都可以）；如果标识符的长度超过了
30
个字母，则基本上以英文单词发音的重读音节取选出三个字母，如
Repeater
用
rpt
，
Management
用
mgt
。
目前一般有两种大小写规则：
Pascal
大小写形式，所有单词第一个字母大写，其他字母小写。
Camel
大小写形式，除了第一个单词，所有单词第一个字母大写，其他字母小写。
n
类名使用
Pascal
大小写形式
public class HelloWorld
（或者
Hello_World
，以下同，不再赘述）
{
...
}
n
方法使用
Pascal
大小写形式
public class HelloWorld
（）
{
void SayHello(string name)
{
...
}
}
n
变量和方法参数使用
Camel
大小写形式
public class HelloWorld
（）
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
...
}
}
n
不要使用匈牙利方法来命名变量
以前，多数程序员喜欢把数据类型作为变量名的前缀而
m_
作为成员变量的前缀。例如：
string m_sName
；
int nAge
；
然而，这种方式在
.NET
编码规范中是不推荐的。所有变量都用
Camel
大小写形式，而不是用数据类型和
m_
来作前缀。
用
name
，
address
，
salary
等代替
nam
，
addr
，
sal
。
别使用单个字母的变量象
i
，
n
，
x
等。使用
index
，
temp
等。用于循环迭代的变量例外：
如果变量只用于迭代计数，没有在循环的其他地方出现，允许用单个字母的变量命名，而不是另外取实义名。
文件名要和类名匹配，例如，对于类
HelloWorld
，相应的文件名应为
helloworld.cs
。
n
缩进用
TAB
，不用
SPACES
。
n
注释需和代码对齐。
n
遵循
VS2005
的自动对齐规则，不要人为的调整。
n
用一个空行来分开代码的逻辑分组。
n
在一个类中，各个方法的实现体必须用空行间隔，大括弧“
{}
”需独立一行。
n
在每个运算符和括号的前后都空一格。如：
If ( showResult == true )
{
for ( int i = 0; i < 10; i++ )
{
//
}
}
而不是：
if(showResult==true)
{
for(int i= 0;i<10;i++)
{
//
}
}
n
避免使用大文件。如果一个文件里的代码超过
300
～
400
行，必须考虑将代码分开到不同类中。
n
避免写太长的方法。一个典型的方法代码在
1
～
30
行之间。如果一个方法发代码超过
30
行，应该考虑将其分解为不同的方法。
n
方法名需能看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了。
n
一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小。
n
使用
C#
的特有类型，而不是
System
命名空间中定义的别名类型。如：
int age;
string name;
object contactInfo;
而不是：
Int16 age;
String name;
Object contactInfo;
这么做是基于如下两点原因：（
1
）规范性和一致性；（
2
）便于跨语言平台的移植。
n
别在程序中使用固定数值，用常量代替。别用字符串常数，尽量用资源文件。
n
避免使用很多成员变量，声明局部变量，并传递给方法。
n
不要在方法间共享成员变量，如果在几个方法间共享一个成员变量，那就很难知道是哪个方法在什么时候修改了它的值。必要时使用
enum
，别用数字或字符串来指示离散值。
n
别把成员变量声明为
public
或
protected
。都声明为
private
而使用
public/protected
的
Properties
。
n
不在代码中使用具体的路径和驱动器名，使用相对路径，并使路径可编程。永远别设想你的代码是在
"C:"
盘运行。你不会知道，一些用户在网络或
"Z:"
盘运行程序。
n
应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据库连接，出现任何问题给用户一个友好的提示。
n
如果需要的配置文件找不到，应用程序需能自己创建使用默认值。如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。错误消息需能帮助用户解决问题。
n
别每行代码，每个声明的变量都做注释。在需要的地方注释。
n
可读性强的代码需要很少的注释，如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。行数不多的注释会使代码看起来优雅。
n
如果因为某种原因使用了复杂艰涩的原理，必须为程序配备良好的文档和详细的注释。
n
对注释做拼写检查，保证语法和标点符号的正确使用。
n
数据表的分类
u
系统表
支撑业务模型的数据表，如流程模型、系统管理相关表。
u
业务表
产品提供的针对业务的通用功能模块相关表，如通用业务查询等。
u
用户表
用户二次开发使用的与具体业务相关的数据表。
n
数据表的命名
u
所有表格命名一律以字母“
T
”开头（
Table
），并且用实义单词以下划线“
_
”间隔。
u
系统表
系统表前缀为：
TSYS_
u
业务表前缀为：
TBIZ_
u
用户表由用户自行定义，但是建议不要与系统表和业务表的命名规则重复。
n
字段的命名
字段的命名规则参照代码标识符的命名规则，但是注意避开数据库的保留字。比如不要采用这样的字段名：
index
，
field
，
password
，
id
，
Oracle
，
SQL
等等。
对于涉及到技术核心的系统表，为了防止剖析，建议采用类似“
F1
，
F2
，
F3
……
Fn
”的方式命名。但是不要采用“
F0”，因为这个名称在某些数据库中不被允许，比如Interbase
。
n
索引是一把双刃剑，索引将提高查询的效率，但是却降低了
insert/delete/update
的效率。
n
通常情况下，对数据的编辑频度和时限要求远远低于对数据库的查询要求，因此对于记录很多且频繁查询的数据表，必须建立索引。
n
大多数数据库为主键字段自动创建索引，注意为外键创建索引。
n
不要索引大字段，这样作会让索引占用太多的存储空间。
n
尽量不要索引频繁编辑的小型表。
n
identify
字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。如果考虑支持多数据库，建议主键采用程序生成的唯一值。
n
如果一个大型表需要频繁的做
insert/delete/update
操作，同时也需要做高并发量的查询，那么建议根据数据的访问频度对表作拆分，而后建立索引。