C# 程序员编程指南
时间:2011-03-21 来源:蓝鸿鹄
1 命名规范
1.1 总体原则
采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线_组成,共63个字符。不能出现其他字符(注释除外)。
以字母作为名称的起始。
避免使用系统关键字以及.net框架中已使用的名称。
避免使用缩写和简写。
例如:用number替代num
避免连续的大写字母
例如:用Id替代ID;用No替代NO
1.2 命名空间
使用Pascal的命名规范命名
使用有意义的名字定义名称空间,例如产品名或者公司名,建议使用公司名.产品名.模块名
例如:Index.UserSystem.DataAccess
1.3 类
使用Pascal的命名规范命名
1.4 字段
使用m_作为前缀。后面使用Pascal命名规范。
例如:m_Number
1.5 属性
使用Pascal的命名规范命名
1.6 方法
使用Pascal的命名规范命名
在命名方法的时候使用动宾结构的短语。
例如:ShowDialog(),UpdateCustomer()
有返回值的方法应该有一个可以描述其返回值的名字。
例如:GetObjectState()
当返回多个对象时宾语使用复数形式,多个对象以IList或数组方式返回
例如:GetCustomersBySex()
在参数不超过两个时,命名时使用By引出简单的查询条件
例如:GetCustomerById(),GetCustomersBySexAndAge()
当返回DataTable时,使用“宾语+Table”
例如:GetCustomerTableBySex()
避免用DataTable返回只可能有一条记录的方法
1.7 参数
使用camel命名规范命名方法的参数。
1.8 局部变量
使用camel命名规范命名局部变量。
使用有意义的变量名称。
a) 避免单字符的变量名,例如i或t等。使用类似于index或temp这样有意义的名字。
b) 对于public或protected类型的变量避免使用匈牙利表示法。
c) 不要缩写单词(例如用num取代number)。
1.9 常量
使用Pascal的命名规范命名
1.10 属性(Attribute)
自定义的属性类使用Attribute作为其后缀。
1.11 接口
使用I作为前缀。
1.12 异常
自定义的异常类使用Exception作为其后缀。
2 使用原则
2.1 命名空间
避免使用完全限定名。而使用using语句替换之。
例如:避免Index.UserSystem.User user=newIndex.UserSystem.User();
避免将using语句写在命名空间的内部。
将所有的框架定义的命名空间为一组,自定义的和第三方的命名空间放在另一组。
例如:
using System;
using System.Collections.
using System.ComponentModel;
using System.Data;
using MyCompany.
using MyControls;
2.2 类
尽可能使用partial classes特性,以提高可维护性。(C#2.0新特性)
2.3 字段
禁止把字段设置为公有,而是通过属性来访问。
2.4 属性
使用属性来替代public或protected类型的成员变量(字段)。
2.5 方法
避免写超过25行代码的方法
避免利用返回值作为函数的错误代码。
只把那些绝对需要的方法定义成public,而其它的方法定义成internal。
不要使用继承下来的new操作符,使用override关键字覆写new的实现。
在一个非密封(non-sealed)类中,总是把那些public和protected的方法定义成virtual。
2.6 参数
避免超过5个参数。如果要传递多个参数,使用结构。
2.7 局部变量
使用C#的预定义的类型而不使用System命名空间中其别名来申明变量。
例如:
使用object 而不是 Object
使用string 而不是 String
使用int 而不是 Int32
在最靠近一个局部变量被使用的地方声明该局部变量。
2.8 常量
除了0和1,绝对不要对数值进行硬编码,通过声明一个常量来代替该数值
只对那些亘古不变的数值使用const关键字,例如一周的天数。
避免对只读(read-only)的变量使用const关键字。在这种情况下,直接使用readonly关键字
例如:
public class MyClass
{
public const int DaysInWeek=7;
pubic readonly int Number;
public MyClass(int someValue)
{
Number=someValue;
}
}
2.9 接口
总是使用接口。
避免只有一个成员的接口。
努力保证一个接口有3~5个成员。
不要让一个接口中成员的数量超过20,而12则是更为实际的限制。
避免在接口中包含事件。
当使用抽象类的时候,提供一个接口。
从来不要假设一个类型支持某个接口。在使用前总是要询问一下。
例如:
SomeType obj1;
ImyInterface obj2;
/*Some code to initialize obj1,then:*/
obj2=obj1 as ImyInterface;
if(obj2!=null)
{
obj2.Method1();
}
else
{
//Handle erro in expected interface
}
2.10 事件
不要提供public的事件成员变量。改用Event Accessor。
例如:
Public class MyPublisher
{
MyDelegate m_SomeEvent;
Public event MyDelegate SomeEvent
{
add
{
m_SomeEvent+=value;
}
remove
{
m_SomeEvent-=value;
}
}
}
避免定义事件处理代理。使用EventHandler<T>或者GenericEventHandler。
避免显示触发事件。使用EventsHelper安全的发布事件。
2.11 异常
只捕捉那些你自己能够显式处理的异常。
如果在catch语句块中需要抛出异常,则只抛出该catch所捕捉到的异常(或基于该异常而创建的其他异常),这样可以维护原始错误所在的堆栈位置。
例如:
catch(Exception exception)
{
MessageBox.Show(exception.Message);
throw;//或throw exception;
}
避免自定义异常类。
当自定义异常类的时候:
a) 让你自定义的异常类从Exception类继承
b) 提供自定义的串行化机制
2.12 泛型
在使用泛型的时候,类型的首字母要大写。当处理.NET中的Type类型的时候,保留Type后缀。(C#2.0新特性)
例如:
//正确
public class LinkedList<K,T>
{…}
//避免
public class LinkedList<KeyType,DataType>
{….}
2.13 注释
在和你的代码缩进处于同一个级别处为该行代码添加注释。
避免对那些很直观的内容作注释。代码本身应该能够解释其本身的含义。由可读的变量名和方法名构成的优质代码应该不需要注释。
注释应该只说明操作的一些前提假设、算法的内部信息等内容。
2.14 文件
避免在同一个文件中放置多个类
避免在一个文件中使用多个名称空间
一个文件名应该能够反映它所对应的类名
当使用一个部分类并把该类分布到不同的文件中时,在每一个文件名末尾都加上该文件实现的部分在类整体中扮演的作用。
例如:
// In MyClass.cs
public partial class MyClass
{…}
//In MyClass.Designer.cs
public partial class MyClass
{…}
避免在一个文件内写多于500行的代码(机器自动生成的代码除外)
2.15 格式
维护严格的代码缩进。不要使用tabs或非标准的缩进,例如一个空格。推荐的缩进4个空格。
一行不要超过80个字符
总是要把花括号“{”放在新的一行
对于if语句,总使用一对{}把下面的语句块包含起来,哪怕只有一条语句也是如此。
2.16 程序集
避免在一个程序集中(assembly)中定义多个Main()方法。
避免friend assemblies,因为这会增加程序集之间的耦合性。
避免让你的代码依赖于运行在某个特定地方的程序集。
在application assembly(EXE client assemblies)中最小化代码量。使用类库来包含业务逻辑。
2.17 枚举
避免显式指定枚举的值
例如:
//正确
public enum Color
{
Red,Green,Blue
}
//避免
public enum Color
{
Red=1,Green=2,Blue=3
}
避免为枚举指定一个类型
例如:
//避免
public enum Color:long
{
Red,Green,Blue
}
2.18 数组
总是使用以零为基数的数组。
总是使用一个for循环显式的初始化一个引用成员的数组:
例如:
public class MyClass
{}
const int ArraySize=100;
MyClass[] array=new MyClass[ArraySize];
For (int index=0;index<array.Length;index++)
{
array[index]=new MyClass();
}
2.19 结构
避免在结构中提供方法
a) 参数化的构造函数是鼓励使用的
b) 可以重载运行符
2.20 其他
不要手动去修改任何机器生成的代码。如果修改了机器生成的代码,修改你的编码方式来适应这个编码标准
避免使用三元条件操作符。
避免利用函数返回的Boolean值作为条件语句。把返回值赋给一个局部变量,然后再检测。
例如:
Bool IsEverythingOK()
{…}
//避免
if(IsEverythingOk())
{…}
//正确
bool ok=IsEverythingOK();
if (ok)
{…}
除非为了和其它语言进行互动,否则绝不要使用不安(unsafe)的代码。
避免显示类型转换。使用as关键字安全的转换到另一个类型。
例如:
Dog dog=new GermanShepherd();
GermanShepherd shepherd=dog as GermanShepherd;
if (shepherd!=null)
{…}
在调用一个代理前,总是检查它是否为null。
不要硬编码向用户显示的字符串。要使用资源。
不要硬编码那些可能会随发布环境变化而变化的字符串,例如数据库连接字符串。
使用String.Empty取代“”
例如:
//避免
string name=“”
//正确
string name=String.Empty;
使用一个长字符串的时候,使用StringBuilder代替string。
当早绑定(early-binding)可能的时候就尽量不要使用迟绑定(late-binding)。
让你的应用程序支持跟踪和日志。
除了要在switch语句块中实现代码跳转,不要使用goto关键字。
总在switch语句的default情形提供一个断言。
例如:
int number=SomeMethod();
swith(number)
{
case 1:
trace.WriteLine(“Case 1:”)
break;
case 2:
trace.Writeline(“Case 2:”)
break;
default:
debug.Assert(false);
dreak;
}
除了在一个构造函数中调用其它的构造函数之外,不要使用this关键字。
例如:
//Example of proper use of ‘this’
public class MyClass
{
public MyClass(string message)
{
}
public MyClass():this(“Hello”)
{
}
}
不要使用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)
}
}
不要使用GC.AddMemoryPressure()
不要依赖HandleCollector
基于《Programming .NET components》2/e中第四章的内容实现Disponse()和Finalize()方法。
总是在unchecked状态下运行代码(出于性能的原因),但是为了防止溢出或下溢操作,要果断地使用checked模式。
例如:
Int CalcPower(int number,int power)
{
int result=1;
for (int count=1;count<=power;count++)
{
checked
{
result*=number;
}
}
return result;
}
使用条件方法来取代显式进行方法调用排除的代码(#if…#endif)
例如:
public class MyClass
{
[Conditional(“MySpecialCondition”)]
public void MyMethod()
{}
}
不要在泛型接口中定义约束。接口级的约束通常可以利用强类型来替代。
例如:
Public class Customer
{}
//避免:
public interface IList<T> where T:Customer
{}
//正确:
public interface ICustomerList:IList<Customer>
不要在接口上定义方法相关的约束。
不要在代理上定义约束。
如果一个类或方法提供了泛型和非泛型版本,那么优先选择泛型版本。