編程代碼命名法

帕斯卡命名法編輯即pascal命名法。命名規(guī)則：當變量名和函式名稱是由二個或二個以上單字連結(jié)在一起，而構(gòu)成的唯一識別字時，用以增加變量和函式的可讀性。單字之間不以空格斷開或連接號（-）、底線（_）連結(jié)，第一個單字首字母采用大寫字母；后續(xù)單字的首字母亦用大寫字母，例如：FirstName、LastName。每一個單字的首字母都采用大寫字母的命名格式,被稱為“Pascal命名法”,源自于Pascal語言的命名慣例，也有人稱之為"大駝峰式命名法"（UpperCamelCase），為駝峰式大小寫的子集在編程中帕斯卡命名法是在命名的時候?qū)⑹鬃帜复髮?，如：程序代碼publicvoidDisplaylnfo（）;stringUserName;二者都是采用了帕斯卡命名法。在C#中，以帕斯卡命名法和駱駝命名法居多。C#中的編碼慣例中，給公共成員變量（public）、私有成員變量（private）、受保護的成員變量（protect）、或內(nèi)部成員變量（internal）命名時，應使用帕斯卡命名法，如score、name、Status均為有效的成員變量名。1“Pascal命名法”可視為一種命名慣例，并無絕對與強制，為的是增加識別和可讀性。一旦選用或設(shè)定好命名規(guī)則，在程式編寫時應保持格式的一致性。駱駝命名法1基本概念駱駝式命名法（又稱駝峰命名法），正如它的名稱CamelCase所表示的那樣，是指混合使用大小寫字母來構(gòu)成變量和函數(shù)的名字。程序員們?yōu)榱俗约旱拇a能更容易的在同行之間交流，所以多采取統(tǒng)一的可讀性比較好的命名方式。例如:有些程序員喜歡全部小寫，有些程序員喜歡用下劃線，所以如果要寫一個myname的變量，他們常用的寫法會有myname、my_name、MyName或者myName。這樣的命名規(guī)則不適合所有程序員閱讀，而利用駝峰命名法來表示，可以增加程序可讀性。例如，下面是分別用駱駝式命名法和下劃線法命名的同一個函數(shù)：printEmployeePaychecks()；print_employee_paychecks()；第一個函數(shù)名使用了駱駝式命名法一一函數(shù)名中的每一個邏輯斷點都有一個大寫字母來標記；第二個函數(shù)名使用了下劃線法-…函數(shù)名中的每一個邏輯斷點都有一個下劃線來標記。駱駝式命名法近年來越來越流行了，在許多新的函數(shù)庫和MicrosoftWindows這樣的環(huán)境中，它使用得相當多。另一方面，下劃線法是c出現(xiàn)后開始流行起來的，在許多舊的程序和UNIX這樣的環(huán)境中，它的使用非常普遍。2應用概述駱駝式命名法(Camel-Case)是電腦程式編寫時的一套命名規(guī)則(慣例)。駱駝式命名法就是當變量名或函式名是由一個或多個單字連結(jié)在一起，而構(gòu)成的唯一識別字時，第一個單詞以小寫字母開始；第二個單詞的首字母大寫或每一個單詞的首字母都采用大寫字母，例如：myFirstName、myLastName,這樣的變量名看上去就像駱駝峰一樣此起彼伏，故得名。駱駝式命名法(Camel-Case)一詞來自Perl語言中普遍使用的大小寫混合格式，而LarryWall等人所著的暢銷書《ProgrammingPerl》(O'Reilly出版)的封面圖片正是一匹駱駝。駱駝式命名法的命名規(guī)則可視為一種慣例，并無絕對與強制，為的是增加識別和可讀性。小駝峰法變量一般用小駝峰法標識。駝峰法的意思是：除第一個單詞之外，其他單詞首字母大寫。譬如intmyStudentCount;變量myStudentCount第一個單詞是全部小寫，后面的單詞首字母大寫。大駝峰法相比小駝峰法，大駝峰法把第一個單詞的首字母也大寫了。常用于類名，函數(shù)名，屬性，命名空間。譬如publicclassDataBaseUser;匈牙利命名法原則匈牙利命名法是一種編程時的命名規(guī)范。基本原則是:變量名=屬性+類型+對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基于容易記憶容易理解的原則。保證名字的連貫性是非常重要的。例子舉例來說，表單的名稱為form，那么在匈牙利命名法中可以簡寫為frm，貝1」當表單變量名稱為Switchboard時，變量全稱應該為frmSwitchboard。這樣可以很容易從變量名看出Switchboard是一個表單，同樣，如果此變量類型為標簽，那么就應命名成IblSwitchboard?？梢钥闯觯傺览ǚ浅１阌谟洃?而且使變量名非常清晰易懂，這樣，增強了代碼的可讀性，方便各程序員之間相互交流代碼。歷史據(jù)說這種命名法是一位叫CharlesSimonyi的匈牙利程序員發(fā)明的，后來他在微軟呆了幾年，于是這種命名法就通過微軟的各種產(chǎn)品和文檔資料向世界傳播開了。大部分程序員不管自己使用什么軟件進行開發(fā)，或多或少都使用了這種命名法。這種命名法的出發(fā)點是把變量名按：屬性+類型+對象描述的順序組合起來，以使程序員作變量時對變量的類型和其它屬性有直觀的了解，下面是HN變量命名規(guī)范。變量屬性屬性部分：c_常量m_c++類成員變量s_靜態(tài)變量類型部分：指針p函數(shù)fn無效v句柄h長整型l布爾浮點型（有時也指文件）雙字dw字符串SZ短整型n雙精度浮點d計數(shù)c（通常用ent）字符eh（通常用e）整型i（通常用n）字節(jié)by字w實型r無符號u描述部分：最大Max最小Min初始化Init臨時變量T（或Temp）源對象Src目的對象Dest3舉例hwnd：h是類型描述，表示句柄，wnd是變量對象描述，表示窗口，所以hwnd表示窗口句柄pfnEatApple：pfn是類型描述，表示指向函數(shù)的指針,EatApple是變量對象描述，所以它表示指向EatApple函數(shù)的函數(shù)指針變量。g_cch：g是屬性描述，表示全局變量,c和ch分別是計數(shù)類型和字符類型，一起表示變量類型，這里忽略了對象描述，所以它表示一個對字符進行計數(shù)的全局變量。上面就是HN命名法的一般規(guī)則。4總結(jié)MFC、句柄、控件及結(jié)構(gòu)的命名規(guī)范：Windows類型樣本變量;MFC類樣本變量HWNDhWnd；CWnd*pWnd；HDLGhDlg；CDialog*pDlg；HDChDC；CDC*pDC；HGDIOBJhGdiObj；CGdiObject*pGdiObj；HPENhPen；CPen*pPen；HBRUSHhBrush；CBrush*pBrush；HFONThFont；CFont*pFont；HBITMAPhBitmap；CBitmap*pBitmap；HPALETTEhPaltte；CPalette*pPalette；HRGNhRgn；CRgn*pRgn；HMENUhMenu；CMenu*pMenu；HWNDhCtl；CState*pState；HWNDhCtl；CButton*pButton；HWNDhCtl；CEdit*pEdit；HWNDhCtl；CListBox*pListBox；HWNDhCtl；CComboBox*pComboBox；HWNDhCtl；CScrollBar*pScrollBar；HSZhszStr；CStringpStr；POINTpt；CPointpt；SIZEsize；CSizesize；RECTrect；CRectrect；一般前綴命名規(guī)范：前綴&類型&實例C類或結(jié)構(gòu)CDocument,CPrintlnfom_成員變量m_pDoc,m_nCustomers變量命名規(guī)范：前綴&類型&描述8實例chchar8位字符chGradechTCHAR女口果_UNICODE定義，則為16位字符chNamebBOOL布爾值bEnablenint整型（其大小依賴于操作系統(tǒng)）nLengthuUINT無符號值（其大小依賴于操作系統(tǒng)）uHeightwWORD16位無符號值wPoslLONG32位有符號整型lOffsetdwDWORD32位無符號整型dwRangep*指針pDoclpFAR*遠指針lpszNamelpszLPSTR32位字符串指針lpszNameIpszLPCSTR32位常量字符串指針I(yè)pszNameIpszLPCTSTR女口果_UNICODE定義，則為32位常量字符串指針I(yè)pszNamehhandleWindows對象句柄hWndIpfncallback指向CALLBACK函數(shù)的遠指針前綴—符號類型：前綴_符號類型實例§范圍IDR_不同類型的多個資源共享標識IDR_MAIINFRAME1?0x6FFFIDD_對話框資源IDD_SPELL_CHECK1?0x6FFFHIDD_對話框資源的Help上下文HIDD_SPELL_CHECK0x20001?0x26FFIDB_位圖資源IDB_COMPANY_LOGO1?0x6FFFIDC_光標資源IDC_PENCIL1?0x6FFFIDI_圖標資源IDI_NOTEPAD1?0x6FFFID_來自菜單項或工具欄的命令I(lǐng)D_TOOLS_SPELLING0x8000?0xDFFFHID_命令Help上下文HID_TOOLS_SPELLING0x18000?0x1DFFFIDP_消息框提示IDP_INVALID_PARTNO8-0xDEEFHIDP_消息框Help上下文HIDP_INVALID_PARTNO0x300040x3DEFFIDS_串資源IDS_COPYRIGHT1?0x7EEFIDC_對話框內(nèi)的控件IDC_RECALC8?0xDEEFMicrosoftMFC宏命名規(guī)范：名稱&類型_AFXDLL唯一的動態(tài)連接庫(DynamicLinkLibrary,DLL)版本_ALPHA僅編譯DECAlpha處理器_DEBUG包括診斷的調(diào)試版本_MBCS編譯多字節(jié)字符集_UNICODE在一個應用程序中打開UnicodeAFXAPIMFC提供的函數(shù)CALLBACK通過指針回調(diào)的函數(shù)庫標識符命名法：標識符&值和含義uANSI(N)或Unicode(U)d調(diào)試或發(fā)行：D=調(diào)試：忽略標識符為發(fā)行。靜態(tài)庫版本命名規(guī)范：庫&描述NAFXCWD.LIB調(diào)試版本：MFC靜態(tài)連接庫NAFXCW.LIB發(fā)行版本：MFC靜態(tài)連接庫UAFXCWD.LIB調(diào)試版本：具有Unicode支持的MFC靜態(tài)連接庫UAFXCW.LIB發(fā)行版本：具有Unicode支持的MFC靜態(tài)連接庫動態(tài)連接庫命名規(guī)范：名稱&類型_AFXDLL唯一的動態(tài)連接庫(DLL)版本W(wǎng)INAPIWindows所提供的函數(shù)Windows.h中新的命名規(guī)范：類型&定義描述WINAPI使用在API聲明中的FARPASCAL位置，如果正在編寫一個具有導出API人口點的DLL，則可以在自己的API中使用該類型CALLBACK使用在應用程序回叫例程，如窗口和對話框過程中的FARPASCAL的位置LPCSTR與LPSTR相同，只是LPCSTR用于只讀串指針，其定義類似(constcharFAR*)UINT可移植的無符號整型類型，其大小由主機環(huán)境決定(對于WindowsNT和Windows9x為32位)；它是unsignedint的同義詞LRESULT窗口程序返回值的類型LPARAM聲明IParam所使用的類型，IParam是窗口程序的第四個參數(shù)WPARAM聲明wParam所使用的類型，wParam是窗口程序的第三個參數(shù)LPVOID一般指針類型，與(void*)相同，可以用來代替LPSTR5反對聲音匈牙利命名法是一種編程時的命名規(guī)范。命名規(guī)范是程序書寫規(guī)范中最重要也是最富爭議的地方，自古乃兵家必爭之地。命名規(guī)范有何用？四個字：名正言順。用二分法，命名規(guī)范分為好的命名規(guī)范和壞的命名規(guī)范，也就是說名正言順的命名規(guī)范和名不正言不順的命名規(guī)范。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規(guī)范具有的破壞力比一個好的命名規(guī)范具有的創(chuàng)造力要大得多。有人認為，匈牙利命名法是一個壞的命名規(guī)范。舉例說明。以靜態(tài)強類型編程語言為例，分析范本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。成本匈法的表現(xiàn)形式為給變量名附加上類型名前綴，例如:nFoo,szFoo,pFoo,cpFoo分別表示整型變量,字符串型變量，指針型變量和常指針型變量?？梢钥闯?，匈法將變量的類型信息從單一地點(聲明變量處)復制到了多個地點(使用變量處)，這是冗余法。冗余法的成本之一是要維護副本的一致性。這個成本在編寫和維護代碼的過程中需要改變變量的類型時付出。冗余法的成本之二是占用了額外的空間。一個優(yōu)秀的書寫者會自覺地遵從一個法則：代碼最小組織單位的長度以30個自然行以下為宜，如果超過50行就應該重新組織。一個變量的書寫空間會給這一法則添加不必要的難度。收益匈牙利命名法的收益是含糊的，無法預期的。范本1:strcpy(pstrFoo,pcstrFoo2)Vsstrcpy(foo,foo2)沒有一個程序員會承認自己不知道strcpy函數(shù)的參數(shù)類型，所以收益為零。范本2：unknown_function(nFoo)Vsunknown_function(foo)收益仍是沒有的。對于一個不知道確定類型的函數(shù)，程序員應該去查看該函數(shù)的文檔，這是一種成本。使用匈法的唯一好處是看代碼的人知道這個函數(shù)要求一個整型參數(shù)，這沒有任何用處。函數(shù)是一種接口，參數(shù)的類型僅僅是接口中的一小部分。諸如函數(shù)的功能、出口信息、線程安全性、異常安全性、參數(shù)合法性等重要信息還是必須查閱文檔。范本3：nFoo=nBarVsfoo=bar使用匈法的唯一好處是看代碼的人知道這里發(fā)生了一個整型變量的復制動作，聽起來沒什么問題，可以安心了。如果他看到的是nFoo=szBar,就沒辦法放心下來了。但是事情并非如此。首先岀現(xiàn)問題的應該是編譯器。另一方面，nFoo=nBar只是在語法上合法而已，看代碼的人真正關(guān)心的是語義的合法性，匈法對此毫無幫助。另一方面，一個優(yōu)秀的書寫者會自覺地遵從一個法則：代碼最小組織單位中的臨時變量以一兩個為宜，如果超過三個就應該重新組織。結(jié)合前述第一個法則，可以得出這樣的結(jié)論：易于理解的代碼本身就應該是易于理解的，這是代碼的內(nèi)建高質(zhì)量。好的命名規(guī)范對內(nèi)建高質(zhì)量的助益相當有限，而壞的命名規(guī)范對內(nèi)建高質(zhì)量的損害比人們想象的要大。實施匈牙利命名法在C語言是難以實施的，在C++語言中是無法實施的。匈法是類型系統(tǒng)的冗余，所以實施匈法的關(guān)鍵是我們是否能夠精確地對類型系統(tǒng)進行復制。這取決于類型系統(tǒng)的復雜性。1=11.內(nèi)置類型：int,char,float,double復制為n,ch,f,d?好像沒有什么問題。但是void應該怎么表示，匈法做不到。2.組合類型：array,union,enum,struct復制為a,u,e,s?并不方便。這里的難點不是為主類型取名，而是