养成良好的编码风格是极其必要的，谁也不愿意看到一堆杂乱无章的代码，将来你或者别人在维护的时候是多么的痛苦，所以，从现在开始，养成良好的编码习惯，包括变量命名，注释，代码缩进
....
。
1 .利用Pascal的方式定义类型、方法名和常量
|
public class SomeClass
{
const int DefaultSize=100;
public SomeMethod()
{
}
}
|
2.
对于局部变量和方法的参数使用骆驼命名法
|
int number;
void MyMethod(int someNumber)
{}
|
3.
接口的名称前加上
I
|
interface ImyInterface
{…}
|
4.
在私有成员变量前面加上
m_
。对于
m_
后面的变量名使用骆驼命名方法
|
public class SomeClass
{
private int m_Number;
}
|
5.对自定义的属性类加上后缀Attribute
6.对自定义的异常类加上后缀Exception
7.方法的命名使用动词----对象对，例如ShowDialog()
8.有返回值的方法的命名中要有返回值的描述，例如GetObjectState()
9.
使用带有说明性的变量名
a) 避免单字符的变量名，例如I或t等。使用类似于index或temp这样有意义的名字。
b) 对于public或protected类型的变量避免使用匈牙利表示法。
c)
不要缩写单词（例如用
num
取代
number
）。
10
．总是使用
C#
预定义而不要使用
System
名称空间中的别名，例如：
使用object而不是Object
使用string而不是String
使用int而不是int32
11.
在使用泛型的时候，类型的首字母要大写。当处理
.NET
中的
Type
类型的时候，保留
Type
后缀。
(C#2.0
新特性
)
|
//正确
public class LinkedList<K,T>
{…}
//避免
public class LinkedList<KeyType,DataType>
{….}
|
12.
使用有意义的名字定义名称空间，例如产品名或者公司名
13.
避免通过全限定方式使用类型名称，使用
using
关键字。
14.
避免在一个名称空间中使用
using
关键字
15.
把所有系统框架提供的名称空间组织到一起，把第三方提供的名称空间放到系统名称空间的下面
|
using System;
using System.Collection.Generic;
using System.ComponentModel;
using System.Data;
using MyCompany;
using MyControls;
|
16.
使用代理推导而不要显式的实例化一个化代理（
C#2.0
新特性）
|
delegate void SomeDelegate();
public void SomeMethod()
{…}
SomeDelegate someDelegate=SomeMethod;
|
17.
维护严格的代码缩进。不要使用
tabs
或非标准的缩进，例如一个空格。推荐的缩进是
3
到
4
个空格。
18.
在和你的代码缩进处于同一个级别处为该行代码添加注释。
19.
所有的注释都应该通过拼写检查。注释中的错误拼写意味着开发进度的延缓。
20.
所有的类成员变量应该被声明在类的顶部，并用一个空行把它们和方法以及属性的声明区分开
|
public class MyClass
{
int m_Number;
string m_Name;
public void SomeMethod1();
public void SomeMethod2();
}
|
21.
在最靠近一个局部变量被使用的地方声明该局部变量。
22.
一个文件名应该能够反映它所对应的类名
23.
当使用一个部分类并把该类分布到不同的文件中时，在每一个文件名末尾都加上该文件实现的部分在类整体中扮演的作用。
例如:
|
// In MyClass.cs
public partial class MyClass
{…}
//In MyClass.Designer.cs
public partial class MyClass
{…}
|
24.
总是要把花括号“
{”
放在新的一行
编码实践
:
1.
避免在同一个文件中放置多个类
2.
一个文件应该只向在一个名称空间内定义类型。避免在一个文件中使用多个名称空间
3.
避免在一个文件内写多于
500
行的代码（机器自动生成的代码除外）
4.
避免写超过
25
行代码的方法
5.
避免写超过
5
个参数的方法。如果要传递多个参数，使用结构。
6.
一行不要超过
80
个字符
7.
不要手动去修改任何机器生成的代码
a)
如果修改了机器生成的代码，修改你的编码方式来适应这个编码标准
b)
尽可能使用
partial classes
特性，以提高可维护性。
(C#2.0
新特性
)
8.
避免对那些很直观的内容作注释。代码本身应该能够解释其本身的含义。由可读的变量名和方法名构成的优质代码应该不需要注释。
9.
注释应该只说明操作的一些前提假设、算法的内部信息等内容。
10.
避免对方法进行注释
a)
使用充足的外部文档对
API
进行说明
b)
只有对那些其他开发者的提示信息才有必要放到方法级的注释中来
11.
除了
0
和
1
，绝对不要对数值进行硬编码，通过声明一个常量来代替该数值
12.
只对那些亘古不变的数值使用
const
关键字，例如一周的天数。
13. 避免对只读(read-only)的变量使用const关键字。在这种情况下，直接使用readonly关键字
|
public class MyClass
{
public const int DaysInWeek=7;
pubic readonly int Number;
public MyClass(int someValue)
{
Number=someValue;
}
}
|
14. 对每一个假设进行断言。平均起来，每5行应有一个断言。
|
using System.Diagnostics;
object GetObject()
{…}
object someObject=GetObject();
Debug.assert(someObject!=null);
|
15.
每一行代码都应该以白盒测试的方式进行审读。
16.
只捕捉那些你自己能够显式处理的异常。
17.
如果在
catch
语句块中需要抛出异常，则只抛出该
catch
所捕捉到的异常（或基于该异常而创建的其他异常），这样可以维护原始错误所在的堆栈位置。
|
catch(Exception exception)
{
MessageBox.Show(exception.Message);
throw;//或throw exception;
}
|
18.
避免利用返回值作为函数的错误代码。
19.
避免自定义异常类。
20.
当自定义异常类的时候：
a) 让你自定义的异常类从Exception类继承
b)
提供自定义的串行化机制
21. 避免在一个程序集中(assembly)中定义多个Main()方法。
22. 只把那些绝对需要的方法定义成public,而其它的方法定义成internal。
23. 避免friend assemblies,因为这会增加程序集之间的耦合性。
24.
避免让你的代码依赖于运行在某个特定地方的程序集。
25. 在application assembly(EXE client assemblies)中最小化代码量。使用类库来包含业务逻辑。
26.
避免显式指定枚举的值
|
//正确
public enum Color
{
Red,Green,Blue
}
//避免
public enum Color
{
Red=1,Green=2,Blue=3
}
|
27.
避免为枚举指定一个类型
|
//避免
public enum Color:long
{
Red,Green,Blue
}
|
28.
对于
if
语句，总使用一对
{}
把下面的语句块包含起来，哪怕只有一条语句也是如此。
29.
避免使用三元条件操作符。
30.
避免利用函数返回的
Boolean
值作为条件语句。把返回值赋给一个局部变量，然后再检测。
|
Bool IsEverythingOK()
{…}
//避免
if(IsEverythingOk())
{…}
//正确
bool ok=IsEverythingOK();
if (ok)
{…}
|
31.
总是使用以零为基数的数组。
32.
总是使用一个
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();
}
|
33. 使用属性来替代public或protected类型的成员变量。
34. 不要使用继承下来的new操作符，使用override关键字覆写new的实现。
35. 在一个非密封（non-sealed）类中，总是把那些public和protected的方法定义成virtual。
36. 除非为了和其它语言进行互动，否则绝不要使用不安（unsafe）的代码。
37.
避免显示类型转换。使用
as
关键字安全的转换到另一个类型。
|
Dog dog=new GermanShepherd();
GermanShepherd shepherd=dog as GermanShepherd;
if (shepherd!=null)
{…}
|
38.
在调用一个代理前，总是检查它是否为
null
。
39. 不要提供public的事件成员变量。改用Event Accessor。
|
Public class MyPublisher
{
MyDelegate m_SomeEvent;
Public event MyDelegate SomeEvent
{
add
{
m_SomeEvent+=value;
}
remove
{
m_SomeEvent-=value;
}
}
}
|
40.
避免定义事件处理代理。
使用EventHandler<T>或者GenericEventHandler。
41.
避免显示触发事件。使用
EventsHelper
安全的发布事件。
42.
总是使用接口。
43.
接口和类中方法和属性的比应该在
2:1
左右。
44.
避免只有一个成员的接口。
45.
努力保证一个接口有
3~5
个成员。
46.
不要让一个接口中成员的数量超过
20
，而
12
则是更为实际的限制。
47. 避免在接口中包含事件。
48.
当使用抽象类的时候，提供一个接口。
49.
在类继承结构中暴露接口。
50.
推荐使用显式接口实现。
51.
从来不要假设一个类型支持某个接口。在使用前总是要询问一下。
|
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
}
|
52.
不要硬编码向用户显示的字符串。要使用资源。
53.
不要硬编码那些可能会随发布环境变化而变化的字符串，例如数据库连接字符串。
54. 使用String.Empty取代””
|
//避免
string name=””;
//正确
string name=String.Empty;
|
55. 使用一个长字符串的时候，使用StringBuilder代替string。
56. 避免在结构中提供方法
a) 参数化的构造函数是鼓励使用的
b)
可以重载运行符
57.
当声明了表态成员的时候，总是要提供一个表态构造函数。
58. 当早绑定(early-binding)可能的时候就尽量不要使用迟绑定（late-binding）。
59. 让你的应用程序支持跟踪和日志。
60.
除了要在
switch
语句块中实现代码跳转，不要使用
goto
关键字。
61. 总在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);
break;
}
|
62.
除了在一个构造函数中调用其它的构造函数之外，不要使用
this
关键字。
|
//Example of proper use of ‘this’
public class MyClass
{
public MyClass(string message)
{ }
public MyClass():this(“Hello”)
{ }
}
|
63.
不要使用
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)
}
}
|
64. 不要使用GC.AddMemoryPressure()
65. 不要依赖HandleCollector
66. 基于《Programming .NET components》2/e中第四章的内容实现Disponse()和Finalize()方法。
67. 总是在unchecked状态下运行代码(出于性能的原因)，但是为了防止溢出或下溢操作，要果断地使用checked模式。
|
Int CalcPower(int number,int power)
{
int result=1;
for (int count=1;count<=power;count++)
{
checked
{
result*=number;
}
}
return result;
}
|
68. 使用条件方法来取代显式进行方法调用排除的代码(#if…#endif)
|
public class MyClass
{
[Conditional(“MySpecialCondition”)]
public void MyMethod()
{}
}
|
69.
不要在泛型接口中定义约束。接口级的约束通常可以利用强类型来替代。
|
Public class Customer
{}
//避免:
public interface Ilist<T> where T:Customer
{}
//正确:
public interface IcustomerList:Ilist<Customer>
|
70.
不要在接口上定义方法相关的约束。
71.
不要在代理上定义约束。
72.
如果一个类或方法提供了泛型和非泛型版本，那么优先选择泛型版本