学步园

Tip1：

Bad practice

private void Method()
{   
int Var1;   
int Var2;   
int Var3;   
//Some more statements
Var1 = 10;
}

Good Practice

private void Method()
{   
int Var2;   
int Var3;   
//Some more statements
int Var1;   
Var1 = 10;
}

这个方法增加的代码的可读性。易于维护和扩展。

Tip 2 ：

如果临时变量只是在一个地方使用，应该避免声明，如下所示。

Bad practice

private string GetData()
{  
string temp;  
temp = expression + ( var1 * var2).ToString();//Some expression which  calculate the desired value  
return temp;
}

Good practice

private string GetData()
{ 
return (expression + (var1 * var2).ToString());
}

Tip 3 

在一类，如果方法中一表达式在不同的重复。封装它，同时提供属性或方法，如下所示。

这样增加了代码的重复使用，易于扩展和维护

Bad practice

public class A
{ 
private int Var1; 
private int Var2; 
private void Method1() 
{   
string s = this.Var1 * this.Var2   //Some more statements.. 
} 
private void Method2() 
{  
string s = this.Var1 * this.Var2  //Some more statements.. 
}
}

Good practice

public class A 
{  
private int Var1;  
private int Var2;  
private int Expression  
{    
get  
{      
return this.Var1 * this.Var2;    
}  
}  
private void Method1()  
{    
string s = this.Expression    //Some more statements..  
}  
private void Method2()  
{    
string s = this.Expression;    
//Some more statements  
}
}

Tip 4

基于一个设计原则 - SRP（单一职责原则）一个类，最好只做一件事，只有一个引起它变化的原因。不要在一个类中放置多个功能。

Bad practice：

不要在一个类中同时放置业务逻辑和持久性逻辑。

下面的 'Customer' 类既包含业务逻辑又包含持久性逻辑。因此，存在有两个理由去改造（业务和数据相联系）。这是违反了单一职责原则。

public class Customer 
{   
//Attributes...   
//Behaviors (CRUD Operations)      
public void Create(some param)   
{     
//Writing code as shown below... 
//Creating Data Connection...     
// Opening connection...     
//Firing a Query against the data store     
//Processing the data...     
//Closing connection...   
}   
//Some more methods.....like Update,Delete,Read etc... 
}

Good practice：

有两组类 - 一组业务和一组持久化的

在下面的片段中，我们有两项类设置一个独有的域逻辑（客户），从而获得通过库类的数据的能力（这是专为数据）。

public class Customer 
{   
//Attributes...   
//Behaviors (CRUD Operations)   
ICustomerRepository rep;   
public Customer():this(new CustomerRepository())
{   
}   
public customer(ICustomerRepository re)  
{     
rep = re;   
}      
public void Create(some param)   
{     
//To get the Data..     
rep.Create(some param);   
}   
//Some more methods.....like Update,Delete,Read etc... 
} 
public interface ICustomerRepository 
{ 
void Create(some param); //Some more methods...
}
public class CustomerRepository : ICustomerRepository 
{  
public void Create(some param) 
{     
//Creating Data Connection...     
// Opening connection...     
//Firing a Query against the data store     
//Processing the data...     
//Closing connection... 
}
//Some more methods ...like update,delete,read etc...
}

Tip 5

总是使用抽象/接口规划程序而不是具体的类。这样有利于扩展、松散耦合、插件。

这也将是符合设计原则之一- 里氏替换原则 - 简单的总结的是，每个子类能替代的基类。

例如：如果要我写一个数据持久化类。

Bad practice

public class SqlRepository 
{  
void Crete(parameters)  
{    
//Logic to get the data...  
}  
void Delete(id)  
{   
//Logic to delete the data based on the id  
}  
//Some more specific methods  
}

Good practice

public interface IRepository 
{   
void Create(object);   
void Delete(id);   //Some more methods... 
} 
public class SqlRepository :IRepository 
{   
void Crete(parameters)   
{    
//Logic to get the data...   
}   
void Delete(id)  
{   
//Logic to delete the data based on the id  
}

Tip 6

移除未使用的变量的代码

Bad practice 

在下面的代码声明了var1，但没有使用

public class A
{
private int var1;
private void Method()
{
//Some statements...
}
}

Good practice

public class A
{
private void Method()
{
//Some statements...
}
}

Tip 7

从代码中删除未使用的方法。这有助于实现高度维护的代码在下面的函数方法片段，但声明没有使用。

Bad practice

public class A      
{
private void Method1()
{
//Some statements...
}
public void Method2()
{
//Some statements
}
}

Good practice

public class A   
{
public void Method2()
{
 //Some statements
}
}

Tip 8                  

删除没有使用类/类型的声明。删除代码中没有使用的命名空间-这通常发生在我们的移除没有使用的类或类型的过程中。

Tip 9

如果你的静态方法要在所有的实体/类型/类中使用，将这个静态方法到实体中。例如：

Bad practice

public class Utility
{
public static void Method1(Customer cust)
{ 
//Some processing on the Entity customer...
} 
public static void Method2(some param)
{
//Some statements
}
}

Good practice

public class Utility     
{
public static void Method2(some param)
{
 //Statements... 
}
}
public class Customer
{
public void Method1()
{
 //Do the processing...
}
}

Tip 10

Bad practice 

public abstract class BaseClass
{
abstract void Method1();
abstract void Method2();
//Some more methods....
}
public class Derived : BaseClass
{   
public  override void Method1()
{
//Some processing...
}
public  override void Method2()
{ //Actually this derived class doesnt need this method2...but since it is abstract in its base class, i have to override to getout of compilation issues...

}
//Some more methods...
}

Good practice 

public class BaseClass
{
public void Method1()
{
//Some processing
}
public void Method2()
{
//Some processing..
}
//Some more methods....
}
public class Derived
{
private BaseClass objBase;
public Derived():this(new BaseClass())
{
}
public Derived(BaseClass obj)
{
objBase = obj;
}
public void Method1()
{
  objBase.Method1();
//If needed some more derived class processing...
}
//Some more methods...
}