C#.NET編碼規範整理

C＃.NET編碼規範整理

 

一、  環境設定 

首先去除VS開發環境中的一些選項如下：

粘貼時調整縮排

將類型的左大括弧置於新行

將方法的左大括弧置於新行

將匿名方法的左大括弧置於新行

將控制塊的左大括弧置於新行

將“else”置於新行

將“catch”置於新行

將“finally”置於新行

複選框去掉.

 

二、  命名規範

1)        通用性

l   標識的總長度不要超過32個字元。

l     標識符的基本文法是以字母和_開始，由字母數字及底線組成的單詞，第一個字元不能是數字。

l     只要合適，在變數名的末尾追加計算限定符（Avg、Sum、Min、Max、Index）。

l     在變數名中使用互補對，如 min/max、begin/end 和 open/close。

l     布爾變數名應該前加或包含 Is(is)。

l   盡量減少使用縮寫，而是使用以一致方式建立的縮寫。縮寫應該只有一個意思；同樣，每個縮寫詞也應該只有一個縮寫。例如，如果用 min 作為 minimum 的縮寫，那麼在所有地方都應這樣做；不要將 min 又用作 minute 的縮寫。

l   在命名函數時包括傳回值的說明，如 GetCurrentWindowName()。

l   避免對不同的元素重用名稱，如名為 ProcessSales() 的常式和名為 iProcessSales 的變數。

l   在命名元素時避免同音異義詞（如 write 和 right），以防在檢查代碼時發生混淆。

l   在命名元素時，避免使用普遍拼錯的詞。另外，應清楚地區拼字之間存在的差異，如 color/colour 和 check/cheque。

l   在內部範圍中避免使用與外部範圍中的名稱相同的名稱。若訪問錯誤變數，則會產生錯誤結果。若變數與同一名稱的關鍵字衝突，則必須在關鍵字前加適當的類型庫以作標識。例如，若有一個名為 date 的變數，只能通過調用 System.Date 來使用內部 Date 函數。

l   介面名稱以首碼“I”開始，後面接一個名詞或名詞片語（如 IComponent），或者接一個描述介面行為的形容詞（如 IPersistable）。不要使用底線，不要過多使用縮寫，因為縮寫會引起混淆。

l   事件處理常式的名稱以一個描述事件類型的名詞開始，後面接尾碼“EventHandler”，如“MouseEventHandler”。 事件參數類的名稱裡要加“EventArgs”尾碼。

l   如果某事件含有“之前”或“之後”的概念，請以現在時或過去時形式使用首碼，如“ControlAdd”或“ControlAdded”。

l   單個長字串拆分成多行寫。當一行被分為幾行時，需要將串聯運算子放在每一行的末尾。

l   SQL Server中不要給預存程序加sp 首碼/不要給使用者定義的函數加 fn_ 首碼/不要給擴充預存程序加 xp_ 首碼。這些首碼是為標識系統保留的。將每個主要的SQL子句放在不同的行上，這樣更容易閱讀和編輯語句。

l   不要使用原義數字或原義字串，如 For i = 1 To 7。而是使用命名常數，如 For i = 1 To NUM_DAYS_IN_WEEK 以便於維護和理解。

2)        變數命名

變數名稱命名規則：形容詞+名詞（或名詞）

1. 屬性（類屬性/類屬性對應的私人變數）

l  類屬性與類屬性對應的私人變數基本一樣。

類屬性對應的私人變數是在類屬性名稱的前面加“_”

如：private int _PageSize;// 類屬性對應的私人變數

public int PageSize { set { _PageSize = value; } }//類屬性

l  注意大小寫要保持一致。每個單詞的第一個字母必須大寫。其它單詞的第一個字母也大寫。單詞之間不加“_”。

l  不要使用public來定義一個屬性。

l  屬性名稱和類名以名詞開始，如 EmployeeName 和 CarAccessory。

1. 私人變數（短期性/長期性）

l  短期性（方法內私人變數/不是經常用的變數）

u  定義前加“_”

u  如：string _strSQL = null;

u  第一個單詞的第一個字母必須小寫，其它單詞第一個字母大寫。單詞之間不加“_”。

l  長期性（類私人變數/方法入口參數）

u  類私人變數：前加“_”，和類屬性對應的私人變數一樣。每個單詞的第一個字母必須大寫。其它單詞的第一個字母也大寫。單詞之間不加“_”。

如：private int _PageSizeTmp;

u  方法入口參數：第一個單詞的第一個字母必須小寫，其它單詞的第一個字母必須大寫。如果只有一個單片語成全小寫。單詞之間不加“_”。

如：public static int SendCTTVOSMS(string mobile,string content)

public static string CallAccountHiVA(string restPhone,string userPhone)

1. 全域變數/靜態變數/常量

l  定義要全部大寫。如：public static int SMS_TYPE = 2;

l  定義部分也可小寫。

如：public static string VOSMS_UserName = "88000002";

l  單詞與單詞之間加“_”分隔。

3)        函數命名

函數命名規則：動詞+名詞（或動詞），每個單詞第一個字母必須大寫。單詞之間不加“_”。

如：public static string GetOrderStatus(int sendMode,int statueID)

函數名和方法名以動詞開始，如 InitNameArray() 和 CloseDialog()。

4)        控制項命名

控制項命名規則：類別+名稱

類別對照表：

首碼	表示類型
frm	視窗
btn	按鈕
cbo	下拉式列表框
txt	文本輸入框
lbl	標籤
img	映像
pic	圖片
div	DIV
grd	網格
scr	捲軸
lst	列表框
sds	SqlDataSource
ods	OleDbDataSource

如按鈕：btnSave

 

首碼	表示類型
b/is	Bool
c	Char
sb	Sbyte
b	Byte
n/i	Int
ui	Uint
l	Long
ul	Ulong
f	Float
d	Double
s/str	String

 

5)        表欄位命名

l   在命名表時，用單數形式表示名稱。例如，使用 Employee，而不是 Employees。

l   在命名表的列時，不要重複表格的名稱；例如，在名為 Employee 的表中避免使用名為 EmployeeLastName 的欄位。

l   不要在列的名稱中包含資料類型。如果後來有必要更改資料類型，這將減少工作量。

6)        Web檔案目錄結構命名

l   與過程名一樣，檔案和檔案夾的名稱也應該精確地說明它們的用途。

l   Web檔案第一個單詞的首字元要小寫其它單詞的首字元要大寫。或全小寫。檔案存在後，在程式中要嚴格按照檔案的大小寫引入檔案。目錄名稱必須全小寫。

l   Web目錄結構：

根---類庫1

類庫…N

解決方案開機檔案

項目發布目錄

    Web原始碼--- inc( JS目錄)

css(CSS目錄)

後台目錄

bin目錄

app_data資料庫目錄

master目錄

其它子功能目錄

app_code類檔案

images圖片目錄

 

三、  注釋規範

1)        在檔案的頭部標明檔案的作者，完成時間，它所完成的主要功能。

2)        程式有過改動後，要寫上修改人、時間、簡單原因說明列表。

如：

/********************************************************************

* 誰建立的 日期 什麼功能描述

* 誰修改的 日期 什麼功能描述

* 誰修添加 日期 什麼功能描述

* 誰修刪除 日期 什麼功能描述

********************************************************************/

 

3)        函數等代碼中的注釋規範都按系統自動的注釋格式

4)        修改代碼時，總是使代碼周圍的注釋保持最新。

5)        在每個常式的開始，提供標準的注釋樣本以指樣本程的用途、假設和限制很有協助。注釋樣本應該是解釋它為什麼存在和可以做什麼的簡短介紹。

6)        避免在程式碼的末尾添加註釋；行章節附註釋使代碼更難閱讀。不過在批註變數聲明時，行章節附註釋是合適的；在這種情況下，將所有行章節附註釋在公用製表位處對齊。

7)        避免雜亂的注釋，如一整行星號。

8)        在部署之前，移除所有臨時或無關的注釋，以避免在日後的維護工作中產生混亂。

9)        如果需要用注釋來解釋複雜的代碼節，請檢查此代碼以確定是否應該重寫它。盡一切可能不注釋難以理解的代碼，而應該重寫它。儘管一般不應該為了使代碼更簡單以便於人們使用而犧牲效能，但必須保持效能和可維護性之間的平衡。

10)    在編寫注釋時使用完整的句子。注釋應該闡明代碼，而不應該增加多義性。

11)    在編寫代碼時就注釋，因為以後很可能沒有時間這樣做。另外，如果有機會複查已編寫的代碼，在今天看來很明顯的東西六周以後或許就不明顯了。

12)    避免多餘的或不適當的注釋，如幽默的不主要的備忘。

13)    使用注釋來解釋代碼的意圖。它們不應作為代碼的聯機翻譯。

14)    注釋代碼中不十分明顯的任何內容。

15)    為了防止問題反覆出現，對錯誤修複和解決方案代碼總是使用注釋，尤其是在團隊環境中。

16)    對由迴圈和邏輯分支組成的代碼使用注釋。這些是協助原始碼讀者的主要方面。

17)    在整個應用程式中，使用具有一致的標點和結構的統一樣式來構造注釋。

18)     用空白將注釋同注釋分隔字元分開。在沒有顏色提示的情況下查看注釋時，這樣做會使注釋很明顯且容易被找到。

19)     為了防止在閱讀代碼時左右滾動原始碼編輯器，每行代碼或注釋不得超過一個顯示屏。

20)     可能多的注釋變數表示的意思。

四、  其它代碼風格/習慣

1)        JS和CSS檔案必需是UTF-8編碼的檔案。

2)        單行的判斷代碼不需要加“{}”。

如：if (_url.Trim().Equals(String.Empty)) return -2;

能簡寫的代碼要簡寫。保證自己寫出來的代碼每一句都是有效代碼。

3)        不要使用VS的自動排版代碼功能。

4)        少用“==”運算。應該使用“.Equals”進行比較。

5)        運算子前後要空一格。如：_TotalPage = _TotalRecord / _PageSize; 這樣做是不會改變代碼意圖的，卻可以使代碼更加容易閱讀。

6)        每一個操作結束後加一個空行。所有代碼裡不能有連續的二個或二個以上的空行。

7)        將大的複雜代碼節分為較小的、易於理解的模組。

8)        近可能的使用TAB鍵來空位。不要使用4個空格來代替TAB鍵。

9)        在分頁檔中不能定義static類型的來傳遞資料。

10)