Tip1：
Bad practice
<a></a>
private void Method()
{
int Var1;
int Var2;
int Var3;
//Some more statements
Var1 = 10;
}
Good Practice
這個方法增加的代碼的可讀性。易于維護和擴充。
Tip 2 ：
如果臨時變量隻是在一個地方使用，應該避免聲明，如下所示。
private string GetData()
{
string temp;
temp = expression + ( var1 * var2).ToString();//Some expression which calculate the desired value
return temp;
Good practice
{
return (expression + (var1 * var2).ToString());
Tip 3
在一類，如果方法中一表達式在不同的重複。封裝它，同時提供屬性或方法，如下所示。
這樣增加了代碼的重複使用，易于擴充和維護
代碼
Tip 4
基于一個設計原則 - SRP（單一職責原則）一個類，最好隻做一件事，隻有一個引起它變化的原因。不要在一個類中放置多個功能。
Bad practice：
不要在一個類中同時放置業務邏輯和持久性邏輯。
下面的 'Customer' 類既包含業務邏輯又包含持久性邏輯。是以，存在有兩個理由去改造（業務和資料相聯系）。這是違反了單一職責原則。
Good practice：
有兩組類 - 一組業務和一組持久化的
在下面的片段中，我們有兩項類設定一個獨有的域邏輯（客戶），進而獲得通過庫類的資料的能力（這是專為資料）。
Tip 5
總是使用抽象/接口規劃程式而不是具體的類。這樣有利于擴充、松散耦合、插件。
這也将是符合設計原則之一- 裡氏替換原則 - 簡單的總結的是，每個子類能替代的基類。
例如：如果要我寫一個資料持久化類。
Tip 6
移除未使用的變量的代碼
Bad practice
在下面的代碼聲明了var1，但沒有使用
public class A
{
private int var1;
private void Method()
//Some statements...
Tip 7
從代碼中删除未使用的方法。這有助于實作高度維護的代碼在下面的函數方法片段，但聲明沒有使用。
public class A
private void Method1()
public void Method2()
//Some statements
public class A
//Some statements
Tip 8
删除沒有使用類/類型的聲明。删除代碼中沒有使用的命名空間-這通常發生在我們的移除沒有使用的類或類型的過程中。
Tip 9
如果你的靜态方法要在所有的實體/類型/類中使用，将這個靜态方法到實體中。例如：
public class Utility
public static void Method1(Customer cust)
//Some processing on the Entity customer...
}
public static void Method2(some param)
public class Utility
public static void Method2(some param)
//Statements...
public class Customer
public void Method1()
//Do the processing...
Tip 10
Good practice
本文轉自麒麟部落格園部落格，原文連結：http://www.cnblogs.com/zhuqil/archive/2010/03/03/Refactoring-Tips.html，如需轉載請自行聯系原作者