命名規範【轉】
1規範目的 ……………………………………………………… 3
2適用範圍 ……………………………………………………… 3
3程式碼註釋 ……………………………………………………… 3
3.1 程式碼註釋約定............................................ 3
3.2 模組頭部註釋規範...................................... 3
3.3 方法註釋規範............................................. 4
3.4 程式碼行註釋規範.......................................... 6
3.5 變數註釋規範............................................. 7
4命名規則 ……………………………………………………… 8
4.1 命名的基本約定.......................................... 8
4.2 各種標示符型別的基本約定......................... 9
4.3 元件名稱縮寫列表....................................... 10
5其它規範 ……………………………………………………… 11
5.1 程式設計風格.................................................. 11
5.2 資源釋放.................................................. 13
5.3 錯誤處理.................................................. 13
5.4 其它......................................................... 14
1 規範目的
- 一個軟體的生命週期中，80%的花費在於維護；
- 幾乎沒有任何一個軟體，在其整個生命週期中，均由最初的開發人員來維護；
- 編碼規範可以改善軟體的可讀性，可以讓程式設計師儘快而徹底地理解新的程式碼。為了執行規範，每個軟體開發人員必須一致遵守編碼規範；
- 使用統一編碼規範的主要原因，是使應用程式的結構和編碼風格標準化，以便於閱讀和理解這段程式碼；
- 好的編碼約定可使原始碼嚴謹、可讀性強且意義清楚，與其它語言約定相一致，並且儘可能的直觀。
2 適用範圍
- 本規範主要以C#為開發語言的規範，為鮑亮實驗室的原則性規範；
- 由於本規範是為撰寫程式而設計，所以適用於一切有關程式撰寫的工作事項。對於具體的每個專案，可能需要對之進行裁剪和補存。
- 適用人員：軟體工程專業的學生；
- 適用產品：以C#編寫的程式。
3 程式碼註釋
3.1 程式碼註釋約定
- 所有的方法和函式都應該以描述這段程式碼的功能的一段簡明註釋開始（方法是幹什麼）。這種描述不應該包括執行過程細節（它是怎麼做的），因為這常常是隨時間而變的，而且這種描述會導致不必要的註釋維護工作，甚至更糟—成為錯誤的註釋。程式碼本身和必要的嵌入註釋將描述實現方法。
- 當引數的功能不明顯且當過程希望引數在一個特定的範圍內時，也應描述傳遞給過程的引數。被過程改變的函式返回值和全域性變數，特別是通過引用引數的那些，也必須在每個過程的起始處描述它們。
3.2模組頭部註釋規範
以一個物理檔案為單元的都需要有模組頭部註釋規範，例如：C#中的.cs檔案
用於每個模組開頭的說明，主要包括：（粗體字為必需部分，其餘為可選部分）
- 檔名稱(File Name)： 此檔案的名稱
- 功能描述(Description)： 此模組的功能描述與大概流程說明
- 資料表(Tables)： 所用到的資料表，檢視，儲存過程的說明，如關係比較複雜，則應說明哪些是可擦寫的，哪些表為只讀的。
- 作者(Author)：
- 日期(Create Date)：
- 參考文件(Reference)(可選)： 該檔所對應的分析文件，設計文件。
- 引用(Using) (可選)﹕ 開發的系統中引用其它系統的Dll、物件時，要列出其對應的出處，是否與系統有關﹙不清楚的可以不寫﹚，以方便製作安裝檔。
- 修改記錄(Revision History)：若檔案的所有者改變，則需要有修改人員的名字、修改日期及修改理由。
- 分割符：*************************** (前後都要)
示例如下：
3.3方法註釋規範
1> C# 提供一種機制，使程式設計師可以使用含有XML 文字的特殊註釋語法為他們的程式碼編寫文件。在原始碼檔案中，具有某種格式的註釋可用於指導某個工具根據這些註釋和它們後面的原始碼元素生成XML。具體應用當中，類、介面、屬性、方法必須有<Summary>節，另外方法如果有引數及返回值，則必須有<Param>及<Returns>節。示例如下：
/// <summary>
/// …
/// </summary>
/// <param name=””></param>
/// <returns></returns>
2> 事件不需要頭註解，但包含複雜處理時（如：迴圈/資料庫操作/複雜邏輯等），應分割成單一處理函式，事件再呼叫函式。
3> 所有的方法必須在其定義前增加方法註釋。
4> 方法註釋採用 /// 形式自動產生XML標籤格式的註釋。
示例圖如下：
5> 在公用類庫中的公用方法需要在一般方法的註釋後新增作者、日期及修改記錄資訊，統一採用XML標籤的格式加註，標籤如下：
<Author>作者</Author> <CreateDate>建立日期</CreateDate> <RevisionHistory> --修改記錄 <ModifyBy>修改作者</ModifyBy> <ModifyDate>修改日期</ModifyDate> <ModifyReason>修改理由</ModifyReason> <ModifyBy>修改作者</ModifyBy> <ModifyDate>修改日期</ModifyDate> <ModifyReason>修改理由</ModifyReason> <ModifyBy>修改作者</ModifyBy> <ModifyDate>修改日期</ModifyDate> <ModifyReason>修改理由</ModifyReason> </RevisionHistory> <LastModifyDate>最後修改日期</LastModifyDate>
6> 一個程式碼檔案如果是由一人編寫，則此程式碼檔案中的方法無需作者資訊，非程式碼檔案作者在此檔案中新增方法時必須要新增作者、日期等註釋。
7> 修改任何方法，必須要新增修改記錄的註釋。
3.4程式碼行註釋規範
1> 如果處理某一個功能需要很多行程式碼實現，並且有很多邏輯結構塊，類似此種程式碼應該在程式碼開始前添加註釋，說明此塊程式碼的處理思路及注意事項等
2> 註釋從新行增加，與程式碼開始處左對齊
3> 雙斜線與註釋之間以空格分開，示例圖如下所示：
3.5變數註釋規範
1> 定義變數時需新增變數註釋，用以說明變數的用途。
2> Class級變數應以採用 /// 形式自動產生XML標籤格式的註釋，示例圖如下所示：
3> 方法級的變數註釋可以放在變數宣告語句的後面，與前後行變數宣告的註釋左對齊，註釋與程式碼間以Tab隔開。
4命名規則
4.1命名的基本約定
1> 要使用可以準確說明變數/欄位/類的完整的英文描述符，如firstName。對一些作用顯而易見的變數可以採用簡單的命名，如在迴圈裡的遞增（減）變數就可以被命名為 “i”。
2> 要儘量採用專案所涉及領域的術語。
3> 要採用大小寫混合，提高名字的可讀性。為區分一個識別符號中的多個單詞，把識別符號中的每個單詞的首字母大寫。不採用下劃線作分隔字元的寫法。
有兩種適合的書寫方法，適應於不同型別的識別符號：
PasalCasing：識別符號的第一個單詞的字母大寫；
camelCasing：識別符號的第一個單詞的字母小寫。
4> 下表描述了不同型別識別符號的大小寫規則：
5> 避免使用縮寫，如果一定要使用，就謹慎使用。同時，應該保留一個標準縮寫的列表，並且在使用時保持一致。
6> 對常見縮略詞，兩個字母的縮寫要採用統一大小寫的方式（示例：ioStream， getIOStream）；多字母縮寫採用首字母大寫，其他字母小寫的方式（示例：getHtmlTag）；
7> 避免使用長名字（最好不超過 15 個字母）。
8> 避免使用相似或者僅在大小寫上有區別的名字。
4.2各種標示符型別的命名約定
1> 程式集命名
實驗室名稱（Lab）+ 專案名稱 + 模組名稱（可選），例如：
中心伺服器程式集：Lab.SeverCenter；
中心伺服器業務邏輯程式集：Lab.SeverCenter.Business；
2> 名稱空間命名
採用和程式集命名相同的方式：實驗室名稱（Lab）+ 專案名稱 + 模組名稱。 另外，一般情況下建議名稱空間和目錄結構相同。例如：
中心伺服器：Lab.SeverCenter；
中心伺服器下的使用者控制元件：Lab.SeverCenter.UserControl；
中心伺服器業務邏輯：Lab.SeverCenter.Business；
中心伺服器資料訪問：Lab.SeverCenter.Data；
3> 程式集和DLL
l 大多數情況下，程式集包含全部或部分可重用庫，且它包含在單個動態連結庫(DLL) 中。
l 一個程式集可拆分到多個DLL 中，但這非常少見，在此準則中也沒有說明。
l 程式集和DLL 是庫的物理組織，而名稱空間是邏輯組織，其構成應與程式集的組織無關。
l 名稱空間可以且經常跨越多個程式集。可以考慮如下模式命名DLL：
<Company>.<Component>.dll
例：Lab.SeverCenter.dll
4>類和介面命名
l 類的名字要用名詞；
l 避免使用單詞的縮寫，除非它的縮寫已經廣為人知，如HTTP。
l 介面的名字要以字母I開頭。保證對介面的標準實現名字只相差一個“I”字首，例如對IComponent介面的標準實現為Component；
l 泛型型別引數的命名：命名要為T或者以T開頭的描述性名字，例如：
public class List<T>
public class MyClass<Tsession>
l 對同一專案的不同名稱空間中的類，命名避免重複。避免引用時的衝突和混淆；
5>方法命名
l 第一個單詞一般是動詞；
l 如果方法返回一個成員變數的值，方法名一般為Get+成員變數名，如若返回的值 是bool變數，一般以Is作為字首。另外，如果必要，考慮用屬性來替代方法；
l 如果方法修改一個成員變數的值，方法名一般為：Set + 成員變數名。同上，考慮 用屬性來替代方法。
6>變數命名
l 按照使用範圍來分，我們程式碼中的變數的基本上有以下幾種型別，類的公有變數；類的私有變數（受保護同公有）；方法的引數變數；方法內部使用的區域性變數。這些變數的命名規則基本相同，見識別符號大小寫對照表。區別如下：
a) 類的公有變數按通常的方式命名，無特殊要求；
b) 類的私有變數採用兩種方式均可：採用加“m”字首，例如mWorkerName;
c) 方法的引數變數採用camalString，例如workerName；
l 方法內部的區域性變數採用camalString，例如workerName。
l 不要用_或&作為第一個字母；
l 儘量要使用短而且具有意義的單詞；
l 單字元的變數名一般只用於生命期非常短暫的變數：i,j,k,m,n一般用於integer；c,d,e 一般用於characters；s用於string
l 如果變數是集合，則變數名要用複數。例如表格的行數，命名應為：RowsCount；
l 命名元件要採用匈牙利命名法，所有字首均應遵循同一個元件名稱縮寫列表
4.3元件名稱縮寫列表
縮寫的基本原則是取元件類名各單詞的第一個字母，如果只有一個單詞，則去掉其中的母音，留下子音。縮寫全部為小寫。
5其它規範
5.1 程式設計風格
1>變數宣告：
為了保持更好的閱讀習慣，請不要把多個變數宣告寫在一行中，即一行只宣告一個變數。
--例如：
String strTest1, strTest2;
--應寫成：
String strTest1;
String strTest2;
2>程式碼縮排：
l 一致的程式碼縮排風格，有利於程式碼的結構層次的表達，使程式碼更容易閱讀和傳閱；
l 程式碼縮排使用Tab鍵實現，最好不要使用空格，為保證在不同機器上使程式碼縮排保持一致，特此規定C#的Tab鍵寬度為4個字元，設定介面如下(工具–選項)：
l 避免方法中有超過5個引數的情況，一般以2,3個為宜。如果超過了，則應使用struct來傳遞多個引數。
l為了更容易閱讀，程式碼行請不要太長，最好的寬度是螢幕寬度（根據不同的顯示分辯率其可見寬度也不同）。請不要超過您正在使用的螢幕寬度。（每行程式碼不要超過80個字元。）
l 程式中不應使用goto語句。
l 在switch語句中總是要default子句來顯示資訊。
l 方法引數多於8個時採用結構體或類方式傳遞
l 操作符/運算子左右空一個半形空格
l 所有塊的{}號分別放置一行，並巢狀對齊，不要放在同一行上
3>空白：
l 空行將邏輯相關的程式碼段分隔開，以提高可讀性。
l 下列情況應該總是使用兩個空行：
a) 一個原始檔的兩個片段(section)之間。
b) 類宣告和介面宣告之間。
l 下列情況應該總是使用一個空行：
a) 兩個方法之間。
b) 方法內的區域性變數和方法的第一條語句之間。
c) 塊註釋（參見"5.1.1"）或單行註釋（參見"5.1.2"）之前。
d) 一個方法內的兩個邏輯段之間，用以提高可讀性。
l 下列情況應該總是使用空格：
a) 空白應該位於引數列表中逗號的後面，如：
void UpdateData(int a, int b)
b) 所有的二元運算子，除了"."，應該使用空格將之與運算元分開。一元操作符和運算元之間不因該加空格，比如：負號("-")、自增("++")和自減("--")。例如：
a += c + d;
d++;
c) for 語句中的表示式應該被空格分開，例如：
for (expr1; expr2; expr3)
d) 強制轉型後應該跟一個空格，例如：
char c;
int a = 1;
c = (char) a;
5.2資源釋放
所有外部資源都必須顯式釋放。例如：資料庫連線物件、IO物件等。
5.3錯誤處理
1> 不要“捕捉了異常卻什麼也不做“。如果隱藏了一個異常，你將永遠不知道異常到底發生了沒有。
2> 發生異常時，給出友好的訊息給使用者，但要精確記錄錯誤的所有可能細節，包括髮生的時間，和相關方法，類名等。
3> 只捕捉特定的異常，而不是一般的異常。
正確做法：
錯誤做法：
5.4其它
1> 一個方法只完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。
2> 使用C#的特有型別，而不是System名稱空間中定義的別名型別。
3> 別在程式中使用固定數值，用常量代替。
4> 避免使用很多成員變數。宣告區域性變數，並傳遞給方法。不要在方法間共享成員變數。如果在幾個方法間共享一個成員變數，那就很難知道是哪個方法在什麼時候修改了它的值。
5> 別把成員變數宣告為 public 或 protected。都宣告為 private 而使用 public/protected 的屬性
6> 不在程式碼中使用具體的路徑和驅動器名。 使用相對路徑，並使路徑可程式設計。
7> 應用程式啟動時作些“自檢”並確保所需檔案和附件在指定的位置。必要時檢查資料庫連線。出現任何問題給使用者一個友好的提示。
8> 如果需要的配置檔案找不到，應用程式需能自己建立使用預設值的一份。
9> 如果在配置檔案中發現錯誤值，應用程式要丟擲錯誤，給出提示訊息告訴使用者正確值。
10> DataColumn取其列時要用欄位名，不要用索引號。
例： 正確DataColumn[“Name”]
不好 DataColumn[0]
11> 在一個類中，欄位定義全部統一放在class的頭部、所有方法或屬性的前面。
12> 在一個類中，所有的屬性全部定義在一個屬性塊中：
【原文連結：https://www.cnblogs.com/haxianhe/p/9271253.html】