前言

　　編碼規範保證了程式的一致性和統一性，對程式設計師尤為重要，原因有以下幾個：

1、一個軟體的生命週期中，80%的花費在於維護。
2、幾乎沒有任何一個軟體，在其整個生命週期中，均由最初的開發人員來維護。
3、編碼規範可以改善軟體的可讀性，可以讓程式設計師儘快而徹底地理解新的程式碼。每個軟體開發人員都必須遵守統一的編碼規範。
4、程式碼儘量簡單直白。

命名規範

1、說明
　　表達清晰的命名規範是程式規劃的核心，如果規範的命名能清晰地表達出相應的功能，就可以讓人“望文知意”，提高開發效率和系統的可維護性。反之，如果命名不能表達其含義，例如，“aaa”、“bbb()”，那麼將事倍功半。
2、Pascal風格
　　包含一到多個單詞，每一個單詞第一個字母大寫，其餘字母均小寫。例如：HelloWorld、SetName等。
3、Camel風格
　　包含一到多個單詞，第一個單詞首字母小寫，其餘單詞首字母大寫。例如：name、productId等。

識別符號的大小寫規則

　　（1）除了引數與變數外，所有名稱空間名稱、類、函式、介面、屬性等名稱的命名，使用Pascal風格。
　　（2）引數與變數的命名使用Camel風格。

通用命名規約

　　約定的是如何選擇最適當的名稱，這些準則適用於所有識別符號的命名。
1、選擇名稱
　　（1）請選擇易讀的英文名稱。例如：英文Order的意思為規則、次序、訂購等，如果用在排序列中就不是很合適，用來表示訂單則更具可讀性。可讀性比詳細描述更重要，比如表示座標名稱的ScreenX就比ScreenHorizontally更具可讀性。
　　（2）除下劃線外，不要使用連字元或任何其他非字母數字字元。在資料庫表字段名稱設計時，與其他表字段有關聯時，適當地使用表名+下劃線+欄位名，可以更清晰地表現出該欄位與關聯表對應欄位的關係。比如產品分類表ProductClass中有欄位Id和Name，那麼產品表繫結的這兩個欄位可命名為ProductClass_Id與ProductClass_Name，這樣在檢視產品表時就可以清晰地知道這兩個欄位與分類表的關係。
　　（3）避免使用與常用程式語言的關鍵字衝突的識別符號。
　　（4）變數和方法引數使用Camel風格。例如：

string productName="";
int number=0;
string sqlString="";
double averageScore=0.0;
Users users=new Users();
Users model=new Users();
Users userModel=new Users();
const string const_String="";
private string GetProductName(int id)
{
    return "";
}

　　（5）不要使用成員屬性作為成員變數的字首（其他變數命名也一樣）。例如：不要像Users m_users;這樣定義成員變數，可以使用第（4）點的設定。
2、字母縮寫詞

名稱空間命名

　　名稱空間的命名採用Pascal風格，取名的一般規則為Jujianfei.ProjectName(人名.專案名稱)，例如：Jujianfei.SetName；需要用複數時，請使用複數，例如：使用System.Collections而不是System.Collection；需要縮寫時，不需要加複數，例如：使用System.IO而不是System.IOs。

類、結構和介面命名

　　（1）按照Pascal大小寫格式，使用名詞或名詞短語為類、介面和值型別命名。
　　（2）介面命名以字母I為字首，例如：Icomponent。
　　（3）派生類的末尾使用基類名稱。例如：從Stream繼承的型別以Stream結尾，從Exception繼承的型別以Exception結尾。

邏輯層類命名

　　按照Pascal大小寫格式，使用名詞或名詞短語命名，並加上字尾Logic。

資料夾命名

　　資料夾以功能模組名稱，按照Pascal大小寫格式命名。比如後端管理功能及許可權相關功能，全部放到System資料夾裡。

程式碼編碼規範

　　（1）縮排和間隔。縮排使用Tab鍵，不用Spaces鍵。
　　（2）註釋需和程式碼對齊。多使用#region和#endregion程式碼塊。
　　（3）在程式碼中垂直對齊左括號和右括號。

if（x==0）
{
    Response.Write("");
}

　　不要出現以下情況。

if（X==0）{
    Response.Write("");
}

　　或者：

if（x==0）{ Response.Write(""); }

　　（4）適當地增加空行，來增加程式碼的可讀性。
　　　　　在下列情況下應該有兩行空行：
　　　　　　　①同一檔案的不用部分之間。
　　　　　　　②在類、介面及彼此之間。

　　　　　在下列情況下應該有一行空行：
　　　　　　　①方法之間。
　　　　　　　②區域性變數和它後邊的語句之間。
　　　　　　　③方法內的功能邏輯部分之間。
　　（5）避免使用大檔案。如果一個檔案裡的程式碼超過300行，必須考慮將程式碼分開到不同的類中。當然，模板生成類與邏輯層類除外。
　　（6）避免寫太長的方法。一個典型的方法程式碼在1-25行之間。如果一個方法程式碼超過25行，應該考慮將其分解為不同的方法。
　　（7）為了防止在閱讀程式碼時不得不滾動原始碼編輯器，每行程式碼或註釋在1024×768的顯示頻率下不得超過一顯示屏。
　　（8）在大多數運算子之前和之後使用空格，這樣做不會改變程式碼的意圖，卻可以使程式碼容易閱讀。。例如：

int j = i + k;

　　而不應該寫：

int j=i+k；

　　括號和它裡面的字元之間不應該出現空格，括號應該和它前面的關鍵詞留有空格。例如：

while (true)
{

}

　　但是方法名和左括號之間不應該有空格。例如：

method(int i1, int i2)

　　for語句裡的表示式之間加空格。例如：

for(int i = 0; i < 10; i++)

　　強制型別轉換時，在型別和變數之間加一個空格。例如：

(int) i;

　　（9）所有可供使用者輸入的欄位值，必須忽略前後空白（不包含密碼）；在對欄位值進行有效性驗證時，對提交進資料庫的內容必須進行SQL注入過濾與XSS過濾。
　　（10）一個方法只能完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。
　　（11）避免使用很多成員變數，宣告區域性變數，並傳遞給方法。
　　（12）不要在方法間共享成員變數，如果在幾個方法間共享一個成員變數，那就很難知道是哪個方法在什麼時候修改了它的值。
　　（13）不在程式碼中使用具體的路徑和驅動器名，使用相對路徑，並使路徑可程式設計。永遠別設想你的程式碼是在“C:”盤執行。你不會知道，一些使用者在網路或“Z:”盤執行程式。
　　（14）應用程式啟動時進行“自檢”並確保所需檔案和附件在指定的位置。如果需要的配置檔案找不到，應用程式需自己建立使用預設值的一份。如果在配置檔案中發現錯誤值，應用程式要丟擲錯誤，給出提示訊息告訴使用者正確值。
　　（15）出現任何問題給使用者一個友好的提示，錯誤訊息需能幫助使用者解決問題。永遠別用像“應用程式出錯”、“發現一個錯誤”等之類的錯誤訊息，而應給出像“更新資料庫失敗，請確保登入ID和密碼正確”的具體訊息。顯示錯誤訊息時，除了說哪裡錯了，還應提示使用者如果解決問題。
　　（16）錯誤處理和異常事件
　　不要“捕捉了異常卻什麼也不做”。如果隱藏了一個異常，你將永遠不知道異常到底發生了沒有。發生異常時，給使用者提示友好的訊息，但要精確記錄錯誤的所有可能細節，包括髮生的時間和相關方法、類名等。別寫太大的try-catch模組。如果需要，為每個執行的任務編寫單獨的try-catch模組。這將很容易找出哪一段程式碼產生異常，並給使用者發出特定的錯誤訊息。如果應用程式需要，可以編寫自己的異常類。自定義異常不應從基類SystemException派生，而要繼承於.IApplicationException。