命名規範 轉載

命名規範

名稱空間的命名　

最好用本身公司名建立頂級的命名空間，再嵌套技術較窄，用戶所在小組或部門，或類所在軟件包的命名空間 如

CompanyName.TechnologyName 　 　　 　　 　　 　　 　　 　　 　　 　　 　　 　

注意：這只是一個原則。第三方公司能夠選擇其它的名字。 避免用公司名稱或其它著名品牌的名稱做爲名稱空間的前綴，這樣會形成兩個公佈的名稱空間有同一個名稱的可能性。

例如： 將微軟提供的Office自動類命名爲Microsoft.Office

　　使用Pascal大寫方式，用逗號分隔邏輯成分。

例如：Microsoft.Office.PowerPoint

　　若是你的品牌使用的是非傳統大寫方式，那麼必定要遵循你的品牌所肯定使用的大寫方式，即便這種方式背離了一般的名稱空間大寫規則。

例如：NeXT.WebObjectsee.cummings

類和類成分的命名

　　類的命名原則是用名詞或名詞短語命名類，使用Pascal大寫。減小類名中縮寫的使用量。不要使用任何類前綴（好比C），不要使用帶下劃線的字符。

例如：public class FileStream {} public class Button {} public class String {}

變量的命名

　　名稱中各單詞首字母均爲大寫。 例如：FindLastRecord RedrawMyForm 在內部範圍中避免使用與外部範圍中的名稱相同的名稱。若訪問錯誤變量，則會產生錯誤結果。若變量與同一名稱的關鍵字衝突，則必須在關鍵字前加適當的類型庫以做標識。
　　例如：如有一個名爲 date 的變量，只能經過調用 System.Date 來使用內部 Date 函數。

函數和方法的命名

　　函數和方法的命名應該以動詞開始，使用Pascal大寫。不要使用帶下劃線的字符。 例如：InitNameArray CloseDialog

接口命名原則

　　使用名詞或名詞短語，或者描述行爲的形容詞來命名接口,使用Pascal大寫。 減小接口名中縮寫的使用量，在接口名前加前綴I，以表示這個類型是一個接口。 例如： IComponent（描述性名詞） ICustomAttributeProvider（名詞短語） IPersistable（形容詞）

參數的命名 　　

　 　使用描述性參數名。參數名應該具備足夠的描述性，這樣在大多數狀況下參數名和它的種類能夠用來肯定它的意思。根據參數的意思來命名參數，而不是根據參數 的種類來命名。咱們但願開發工具能夠用很方便的方式提供關於參數種類的信息，這樣參數名能夠獲得更好的使用，能夠對語義而不是對種類進行描述。可是偶爾使 用根據類型命名的參數名也是徹底能夠的。不要使用保留參數。若是在下一個版本中須要更多的數據，能夠增長進來。 　　例如：Type GetType (string typeName) string Format (string format, object [ ] args)

屬性的命名

　　用名詞或名詞短語命名屬性，屬性與類型要同樣。 用與一個類型的名稱相同的名字來命名屬性時，就使這個屬性的類型成爲那個類型。雖然聽起來有些奇怪，但這是正確的。
　　例如：public enum Color {...} public class Control { public Color Color {get {...} set {...}} }

事件的命名

　　用EventHandloer 後綴命名事件處理程序，使用名爲sender和e的兩個參數，Sender參數表明提出事件的對象。Sender參數永遠是一個類型對象，即便它可能使用 了更爲特定的類型，與事件相關的狀態被封裝在一個名爲e的事件類範例中。要使用這個類型的正確的、特定的事件類。
　　例如：public delegate void MouseEventHandler(object sender, MouseEvent e); 命名事件名時，須要有以前和以後的時態概念，所以要使用如今時態和過去時態（不要使用BeforeXxx\\AfterXxx的方式）。例如，能夠被取消的結束事件就有Closing事件和Closed事件。

長項和經常使用項的命名

　　可以使用縮寫使名稱長度適中，一般，多於 32 個字符的變量名在低分辨率的監視器上難以閱讀。同時，請確保縮寫在整個應用程序中保持一致。
　　例如：可使用「HTML」代替「HyperText Markup Language」。

代碼書寫格式規範

• 文件之中不得存在無規則的空行，好比說連續十個空行。通常來說函數與函數之間的空行爲2-3行。
• 在函數體內部，在邏輯上獨立的兩個函數塊可適當空行，通常爲1-2行。
• 每行長度儘可能避免超過屏幕寬度，應不超過80個字符。
• 儘可能用公共過程或子程序去代替重複的功能代碼段。
• 使用括號清晰地表達算術表達式和邏輯表達式的運算順序。如將 x=a*b/c*d 寫成 x=(a*b/c)*d可避免閱讀者誤解爲x=(a*b)/(c*d)。
• 避免採用過於複雜的條件測試。
• 避免過多的循環嵌套和條件嵌套。
• 一個函數不要超過200行。一個文件應避免超過2000行。
• 避免使用goto語句。
• 避免採用多賦值語句，如x = y = z;。

代碼註釋規範

　　.cs文件的註釋 　　 全部.cs文件開頭都要加上註釋，寫明文件建立時間、做者、用途概述等 　　例如：

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

//新增日期:2004.7.19

//做者:XXX

//內容說明:　XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

　　函數過程註釋 　　全部的函數體開頭都要加上註釋，因此註釋使用.NET註釋規範。 　　例如：

/// <summary>

/// 構造函數

/// </summary>

/// <param name='is_xxx1'>示例參數1</param>

/// <param name='is_xxx2'>示例參數2</param>

public UpgradeThread(string is_xxx1, string is_xxx2)

{

//… }

　　常量變量註釋 　　全部的常量變量，不管是全局仍是局部使用的，凡是對代碼總體起到關鍵性作用的都須要加上註釋。 　　例如：

/// <summary>

/// 當前線程指向的備份文件本地保存路徑

/// </summary>

public string StorePath = '';

　　代碼修改註釋 　　當開發者維護之前的程序代碼時，須要在修改處的開始及結尾，加上本身的註釋信息。 　　例如：

//BEGIN 2004-7-19 Jayson　修正了XXX問題 略… //END 2004-7-19 Jayson
網站文件命名規則

　　關於文件的命名，看似無足重輕，但實際上若是沒有良好的命名規則進行必要的約束，一味的亂起名稱，最終致使的結果就是整個網站或是文件夾沒法管理。因此，命名規則在這裏一樣很是重要。 須要特別注意的時候，網站文件或文件夾命名請儘可能避免使用中文字符命名。

文件的命名

　　以最少的字母達到最容易理解的意義。 索引文件統一使用index.html文件名(小寫) index.html文件統一做爲"橋頁"，不製做具體內容，僅僅做爲跳轉頁和meta標籤頁。主內容頁爲main.html。 　　按菜單名的英語翻譯取單一單詞爲名稱。全部單英文單詞文件名都必須爲小寫，全部組合英文單詞文件名第二個起第一個字母大寫； 全部文件名字母間連線都爲下劃線。 　　例如： 關於咱們 \aboutus 信息反饋 \feedback
產　　品 \product

圖片的命名

　　以圖片英語字母爲名。以最少的字母達到最容易理解的意義。 對於較小的圖片，咱們使用以下格式的命名 ： sm.kahn.gif 其中，sm 表明「small」，kahn 表明圖片的內容。較大圖像的命名規則也同樣，不過是以 bg 開頭的： bg.kahn.gif 用以區分不一樣圖像的命名規則應當是全站通用的，這樣能夠儘可能避免將不一樣的名稱攪混。

網站目錄的命名

　　目錄創建的原則是以最少的層次提供最清晰簡便的訪問結構。 服務器的ftp上傳目錄默認爲html 根目錄文件 根目錄只容許存放index.html和main.html文件，以及其餘必須的系統文件。 每一個語言版本存放於獨立的目錄。已有版本語言設置爲： 簡體中文 \gb 繁體中文 \big5 英 語 \en 日 語 \jp 每一個主要功能(主菜單)創建一個相應的獨立目錄。 根目錄下的images爲存放公用圖片目錄，每一個目錄下私有圖片存放於各自獨立images目錄. 　　例如： \menu1\images 　　　　　　\menu2\images 　　另外，全部的js文件存放在根目錄下統一目錄\script 全部的CSS文件存放在根目錄下的style目錄 全部的CGI程序存放在根目錄並列目錄\cgi_bin目錄。 對於一些信息更新量比較大的站點或是欄目，還能夠採用一種更爲特殊的方式來進行文件架的命名，這樣能使得往後的維護更加方便，這樣的方式就是使用「單 一單詞命名的目錄」+「年年年年_月月_日日」的方式命名，最後的「日日」是根據更新量大小可選擇的，若是每日更新量很大則能夠加上「日日」。 　　例如： \news\2005_08\ 　　　　　　\news\2005_09\ 　　　　　　\news\2005_10_12\

CSS類及id中的命名規則

　 　Web開發人員能夠經過建立CSS類及id名稱並使用這些名稱來對divs以及其餘的格式頁面元素進行標識。對開發人員來講，在命名從新定義XHTML 標記（tags）的CSS selectors時，必須保證其與預約義的標記準確匹配，但就類以及id選擇器名稱而言，則仁者見仁，智者見智。然而爲所欲爲的爲這些類以及id命名則 並非個好的習慣。

直觀命名

　　當在設計Web頁面以及須要對一個div進行標識的時候，最天然的想法就是使用能夠描述元素所在頁面位置的詞彙來對其命名。 例如：top-panel horizontal-nav left-side center-column right-col

　　這些是CSS以及XHTML類和id的有效命名方式。這些詞彙簡單而且可以令人顧名思義，所以知足了標識頁面元素以及相應的CSS樣式的須要。

　　但問題是這樣的名稱同頁面內容的特定表達方式相關聯。這些命名參考了某種特定頁面佈局中的頁面元素位置，所以在這樣的佈局以外使用就會顯得不合適甚至形成理解混亂。這些命名沒有涉及文檔內容的結構。所以，下面給出了對CSS類以及ID命名更好的方法。

結構化命名

　 　這些是CSS以及XHTML類和id的有效命名方式。這些詞彙簡單而且可以令人顧名思義，所以知足了標識頁面元素以及相應的CSS樣式的須要。 這些是CSS以及XHTML類和id的有效命名方式。這些詞彙簡單而且可以令人顧名思義，所以知足了標識頁面元素以及相應的CSS樣式的須要。

　 　有標記的相關信息都是用來描述文檔的結構而不是外觀。這樣的特色使得咱們能夠經過簡單的改變CSS的方式來對不一樣外觀格式下的內容（content）以 及標記（markup）進行重用。當你理解這種方式時，很容易就能夠發現採用頁面位置來爲類以及id命名的方式在處理如音頻（audio）等外觀格式上顯 得很是不合適。所以，應當根據在文檔中的使用目的而非出現位置來對類以及id進行結構化命名。

　　能夠按照以下所示的結構化方式來對類以及id名稱命名： 例如：branding main-nav subnav main-content 　　　　　sidebar

　　這些名字同直觀命名方式同樣很是易懂，但他們描述了頁面元素的做用而非位置。這使得代碼更加符合使用純粹的結構化標記（structural markup）的初衷，即開發人員能夠在不改變標記的狀況下對各類各樣媒體下的顯示格式進行處理。

　 　即便你不打算在其餘的媒體上對Web頁面進行格式修改，使用結構化命名方式還能夠幫助你在往後的站點升級或從新設計中更爲輕鬆。例如，結構化命名避免了 當一個div同id right-column移動到頁面左邊後所帶來的混亂。對div sidebar的採用這樣的命名方式就顯得更加適當，由於不管它出如今頁面的哪一邊，這個名字仍然對開發人員來講直觀易懂。

慣例

Andy Clarke分析了40份由推崇標準化Web設計理念的開發人員所設計的Web站點的源代碼。儘管類以及id名稱很不統一，可是仍是發現了一些頻繁出現的經常使用名稱。這裏給出了最經常使用類/id名稱的示例列表：

　　例如：header content nav sidebar 　　　　　footer

 

返回導航　　

數據庫中的命名規則

數據庫涉及字符規則

採用26個英文字母（區分大小寫）和0 －9這十個天然數，加上下劃線_組成，共63個字符。不能出現其餘字符（註釋除外）。

據庫對象命名規則

數據庫對象包括表、視圖（查詢）、存儲過程（參數查詢）、函數、約束。對象名字由前綴和實際名字組成，長度不超過30。前綴：使用小寫字母。

　　例如：

表 tb 視圖 vi 存儲過程 sp 函數 fn

實際名字

實際名字儘可能描述實體的內容，由單詞或單詞組合，每一個單詞的首字母大寫，其餘字母小寫，不以數字和_開頭。 　　例如：

表 User_Info 視圖 UserList 存儲過程 UserDelete

所以，合法的對象名字相似以下。

表 tbUser_Info、tbMessage_Detail 視圖 vi_MessageList 存儲過程 sp_MessageAdd

數據庫表命名規則

字段由前綴和實際名字組成。實際名字中首單詞一個系統儘可能採起同一單詞。 前綴：使用小寫字母tb，表示表。 例如：tbMember tbMember_Info tbForum_Board tbForum_Thread1

字段命名規則

　　數字、字符、日期/時間、lob(大對象)、雜項，字段由表的簡稱、下劃線，實際名字加後綴組成。 　　後綴：使用小寫字母，表明該字段的屬性。 　　 例如: 　User_Idint 　　　　 　 User_Namestr 　　　　 　 User_RegDatedtm

視圖命名規則

字段由前綴和實際名字組成，中間用下劃線鏈接。 前綴：使用小寫字母vi，表示視圖。 　　例如：vi_User vi_UserInfo

存儲過程命名規則

字段由前綴和實際名字組成，中間用下劃線鏈接。 前綴：使用小寫字母sp，表示存儲過程。 　　　　例如：sp_User

數據庫設計文檔規則

全部數據庫設計要寫成文檔，文檔以模塊化形式表達。大體格式以下： '------------------------------------------- '　　表名：　　tbUser_Info　　 '　　創建人：UAM_Richard '　　日期：　　2004-12-17 '　　版本：　　1.0 '　　描述：　　保存用戶資料 '　　具體內容： '　　UserId　　int，自動增量　　用戶代碼 '　　UserName　　char(12)　　用戶名字 '　　...... '--------------------------------------------

sql語句規則

全部sql關鍵詞所有大寫，好比SELECT,UPDATE,FROM,ORDER,BY等。

 

返回導航　　
後記：

　　良好的命名對於軟件開發起着相當重要的做用，可以對資源進行合理的命名，能夠達到事半功倍的效果。不管是哪一種命名規則，不管是對哪一種資源進行命名，其核心思想都是「用最少的字母進行最全面的描述」。正如本文開始時強調的，「惟一性＋描述性」是命名的靈魂。因此，在您對程序的各個方面進行命名的時候，不妨去參照着這兩大原則去進行，切記不可圖一時之快，卻爲往後的修改或維護帶來巨大的困難。