轉自h_h學習筆記
1.命名慣例和規範
註記 :
Pascal 大小寫形式－所有單詞第一個字母大寫，其他字母小寫。
Camel 大小寫形式－除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。
Ø 類名使用Pascal 大小寫形式
public class HelloWorld{ ...}
Ø 方法使用Pascal 大小寫形式
public class HelloWorld{ void SayHello(string name) { ... }}
Ø 變量和方法參數使用Camel 大小寫形式
public class HelloWorld
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
...
}
}
Ø 根據類的具體情況進行合理的命名
以Class聲明的類，都必須以名詞或名詞短語命名，體現類的作用。如：
Class Indicator
當類只需有一個對象實例（全局對象，比如Application等），必須以Class結尾，如
Class ScreenClass
Class SystemClass
當類只用於作爲其他類的基類，根據情況，以Base結尾：
Class IndicatorBase
Ø 不要使用匈牙利方法來命名變量
以前，多數程序員喜歡它－把數據類型作爲變量名的前綴而m_作爲成員變量的前綴。例如：
string m_sName; int nAge;
然而，這種方式在.NET編碼規範中是不推薦的。所有變量都用camel 大小寫形式，而不是用數據類型和m_來作前綴。
Ø 控件命名
建議是使用控件名簡寫作爲前綴，並且簡寫的首字母小寫，符合Camel規範。
格式：控件名簡寫+英文描述，英文描述首字母大寫
主要控件名簡寫對照表
Label lbl
TextBox txt
Button btn
CheckBox chk
RadioButton rdo
CheckBoxList chklst
RadioButtonList rdolst
ListBox lst
DropDownList ddl
DataGrid dg
DataList dl
Image img
Table tbl
Panel pnl
LinkButton lnkbtn
ImageButton imgbtn
Calender cld
AdRotator ar
RequiredFieldValidator rfv
CompareValidator cv
RangeValidator rv
RegularExpressionValidator rev
ValidatorSummary vs
CrystalReportViewer rptvew
Ø 用有意義的，描述性的詞語來命名變量
別用縮寫。用name, address, salary等代替 nam, addr, sal
別使用單個字母的變量象i, n, x 等. 使用 index, temp等
用於循環迭代的變量例外：
for ( int i = 0; i < count; i++ ){ ...}
如果變量只用於迭代計數，沒有在循環的其他地方出現，許多人還是喜歡用單個字母的變量(i) ，而不是另外取名。
變量名中不使用下劃線 (_) 。
Ø 文件名要和類名匹配
例如，對於類HelloWorld, 相應的文件名應爲 HelloWorld.cs (或, HelloWorld.vb)
2.良好的編程習慣
遵從以下良好的習慣以寫出好程序
1) 避免使用大文件。如果一個文件裏的代碼超過300～400行，必須考慮將代碼分開到不同類中。
2) 避免寫太長的方法。一個典型的方法代碼在1～25行之間。如果一個方法發代碼超過25行，應該考慮將其分解爲不同的方法。
3) 方法名需能看出它作什麼。別使用會引起誤解的名字。如果名字一目瞭然，就無需用文檔來解釋方法的功能了。
好：
void SavePhoneNumber ( string phoneNumber ) { // Save the phone number. }
不好：
// This method will save the phone number.
void SaveData ( string phoneNumber ) { // Save the phone number. }
4) 一個方法只完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。
5) 使用C# 或 VB.NET的特有類型，而不是System命名空間中定義的別名類型。（爲什麼）
好： int age; string name; object contactInfo;
不好： Int16 age; String name; Object contactInfo;
6) 別在程序中使用固定數值，用常量代替。
7) 別用字符串常數。用資源文件。（爲什麼）
8) 必要時使用enum 。別用數字或字符串來指示離散值。
好：
enum MailType { Html, PlainText, Attachment }
void SendMail (string message, MailType mailType)
{
switch ( mailType )
{
case MailType.Html:
// Do something
break;
case MailType.PlainText:
// Do something
break;
case MailType.Attachment:
// Do something
break;
default:
// Do something
break;
}
}
不好：
void SendMail (string message, string mailType)
{
switch ( mailType )
{
case "Html":
// Do something
break;
case "PlainText":
// Do something
break;
case "Attachment":
// Do something
break;
default:
// Do something
break;
}
}
9) 別把成員變量聲明爲 public 或 protected。都聲明爲 private 而使用 public/protected 的Properties. 而且，成員變量前綴爲“_”。
10) 不在代碼中使用具體的路徑和驅動器名。 使用相對路徑，並使路徑可編程。
永遠別設想你的代碼是在“C:”盤運行。你不會知道，一些用戶在網絡或“Z:”盤運行程序。
11) 人性化消息提示。
錯誤消息需能幫助用戶解決問題。永遠別用象"應用程序出錯", "發現一個錯誤" 等錯誤消息。而應給出象 "更新數據庫失敗。請確保登陸id和密碼正確。" 的具體消息。
顯示錯誤消息時，除了說哪裏錯了，還應提示用戶如何解決問題。不要用 象 "更新數據庫失敗。"這樣的，要提示用戶怎麼做："更新數據庫失敗。請確保登陸id和密碼正確。"
顯示給用戶的消息要簡短而友好。但要把所有可能的信息都記錄下來，以助診斷問題。
12）多使用StringBuilder替代String
String對象是不可改變的。每次使用System.String類中的方法之一時，都要在內存中創建一個新的字符串對象，這就需要爲該新對象分配新的空間。在需要對字符串執行重複修改的情況下，與創建新的String對象相關的系統開銷可能會非常昂貴。如果要修改字符串而不創建新的對象，則可以使用System.Text.StringBuilder類。例如，當在一個循環中將許多字符串連接在一起時，使用StringBuilder類可以提升性能。
以下方法常用於修改StringBuilder的內容。
StringBuilder.Append 將信息追加到當前StringBuilder的結尾。
StringBuilder.AppendFormat 用帶格式文本替換字符串中傳遞的格式說明符。
StringBuilder.Insert 將字符串或對象插入到當前StringBuilder對象的指定索引處。
StringBuilder.Remove 從當前StringBuilder對象中移除指定數量的字符。
StringBuilder.Replace 替換指定索引處的指定字符。
3.註釋
Ø 文件頭部註釋
在代碼文件的頭部進行註釋，標註出創始人、創始時間、修改人、修改時間、代碼的功能，這在團隊開發中必不可少，它們可以使後來維護/修改的同伴在遇到問題時，在第一時間知道他應該向誰去尋求幫助，並且知道這個文件經歷了多少次迭代、經歷了多少個程序員的手。
樣本：
/********************************************************************************
** 作者： Eunge
** 創始時間：2004-6-8
** 修改人：Koffer
** 修改時間：2004-12-9
** 修改人：Ken
** 修改時間：2005-01-29
** 描述：
** 主要用於產品信息的資料錄入，…
*********************************************************************************/
我們甚至可以在這段文件頭註釋中加入版權信息、文件名、版本信息等。
Ø 函數、屬性、類等註釋 （可擴充）
請使用///三斜線註釋，這種註釋是基於XML的，不僅能導出XML製作幫助文檔，而且在各個函數、屬性、類等的使用中，編輯環境會自動帶出註釋，方便你的開發。以protected，protected Internal，public聲明的定義註釋請都以這樣命名方法。
例如：
/// <summary>
/// 用於從ERP系統中撈出產品信息的類
/// </summary>
class ProductTypeCollector
{
…
}
Ø 邏輯點註釋
在我們認爲邏輯性較強的地方加入註釋，說明這段程序的邏輯是怎樣的，以方便我們自己後來的理解以及其他人的理解，並且這樣還可以在一定程度上排除BUG。在註釋中寫明我們的邏輯思想，對照程序，判斷程序是否符合我們的初衷，
如果不是，則我們應該仔細思考修改的是註釋還是程序了。（有些深奧）
4.異常處理（*供參考）
什麼時候用Try catch?
什麼時候用Finally?
1) 數據庫操作
2) 文件操作
不要“捕捉了異常卻什麼也不做“。如果隱藏了一個異常，你將永遠不知道異常到底發生了沒有。
發生異常時，給出友好的消息給用戶，但要精確記錄錯誤的所有可能細節，包括髮生的時間，和相關方法，類名等。
只捕捉特定的異常，而不是一般的異常。
好：
void ReadFromFile ( string fileName )
{
try { // read from file. }
catch (FileIOException ex) {
// log error. // re-throw exception depending on your case.
throw;
}
}
不好：
void ReadFromFile ( string fileName )
{
try { // read from file. }
catch (Exception ex) {
// Catching general exception is bad.
// was a file error or some other error.
// Here you are hiding an exception.
// In this case no one will ever know that an exception happened.
return "";
}
}
不必在所有方法中捕捉一般異常。不管它，讓程序崩潰。這將幫助你在開發週期發現大多數的錯誤。
你可以用應用程序級（線程級）錯誤處理器處理所有一般的異常。遇到”以外的一般性錯誤“時，此錯誤處理器應該捕捉異常，給用戶提示消息，在應用程序關閉或用戶選擇”忽略並繼續“之前記錄錯誤信息。
不必每個方法都用try-catch。當特定的異常可能發生時才使用。比如，當你寫文件時，處理異常FileIOException.
別寫太大的 try-catch 模塊。如果需要，爲每個執行的任務編寫單獨的 try-catch 模塊。 這將幫你找出哪一段代碼產生異常，並給用戶發出特定的錯誤消息
如果應用程序需要，可以編寫自己的異常類。自定義異常不應從基類SystemException派生，而要繼承於IApplicationException。