在程式設計的時候，特別是比較大的程式，最頭疼的往往不是演算法設計和資料結構的設計，而是如何給類、函式、變數命名。
當然，如果你不追求完美，大可不必為此操心。
至今知道比較系統的命名法則是所謂的「匈牙利命名法」。
以下是在網上找的資料：
匈牙利命名法**
mfc、控制代碼、控制項及結構的命名規範
在程式設計時，變數、函式的命名是乙個極其重要的問題。好的命名方法使變數易於記憶且程式可讀性大大提高。microsoft採用匈牙利命名法來命名windows api函式和變數。匈牙利命名法是由microsoft的著名開發人員、excel的主要設計者查爾斯·西蒙尼在他的博士**中提出來的，由於西蒙尼的國籍是匈牙利，所以這種命名法叫匈牙利命名法。
匈牙利命名法為c識別符號的命名定義了一種非常標準化的方式，這種命名方式是以兩條規則為基礎：
1.識別符號的名字以乙個或者多個小寫字母開頭，用這些字母來指定資料型別。
2.在識別符號內，字首以後就是乙個或者多個第乙個字母大寫的單詞，這些單詞清楚地指出了源**內那個物件的用途。比如，m_szstudentname表示乙個學生名字的類成員變數，資料型別是字串型。
a array
b boolean
by byte
c char //有符號型字元
cb char byte //無符號型字元（沒多大用處）
cr colorref //顏色參考值
cx,cy length of x,y (shortint) //座標差（長度）
dw double word
fn function
h handle
i integer
m_ member of a class
n short integer
np near pointer
p pointer lp long pointer
s string
sz string with zero end //以字元'/0'結尾的字串
tm text //文字內容
w word
x,y coordinate //座標
可是在實際使用的時候。這種命名方法往往顯得太麻煩。而且其作用也沒有那麼明顯。因為這種匈牙利命名法只規定了標準型別的縮寫。而實際上我們要用到的物件的型別千變萬化，標準型別的變數只是少數，很難給每個類都定義乙個對應的縮寫。
果然，在網上同樣有人抱怨這種命名法不甚好用。
下面是網上的資料：
抨擊匈牙利命名法
匈牙利命名法是一種程式設計時的命名規範。命名規範是程式書寫規範中最重要也是最富爭議的地方，自古乃兵家必爭之地。命名規範有何用？四個字：名正言順。用二分法，命名規範分為好的命名規範和壞的命名規範，也就是說名正言順的命名規範和名不正言不順的命名規範。好的舞鞋是讓舞者感覺不到其存在的舞鞋，壞的舞鞋是讓舞者帶著鐐銬起舞。乙個壞的命名規範具有的破壞力比乙個好的命名規範具有的創造力要大得多。
一 匈牙利命名法的成本
匈法的表現形式為給變數名附加上型別名字首，例如：nfoo,szfoo,pfoo,cpfoo分別表示整型變數，字串型變數，指標型變數和常指標型變數。可以看出，匈法將變數的型別資訊從單一地點（宣告變數處）複製到了多個地點（使用變數處），這是冗餘法。冗餘法的成本之一是要維護副本的一致性。這個成本在編寫和維護**的過程中需要改變變數的型別時付出。冗餘法的成本之二是占用了額外的空間。乙個優秀的書寫者會自覺地遵從乙個法則：**最小組織單位的長度以30個自然行以下為宜，如果超過50行就應該重新組織。乙個變數的書寫空間會給這一法則新增不必要的難度。
二 匈牙利命名法的收益
這裡要證明匈牙利命名法的收益是含糊的，無法預期的。
範本1：strcpy(pstrfoo,pcstrfoo2) vs strcpy(foo,foo2)
匈法在這裡有什麼收益呢？我看不到。沒有乙個程式設計師會承認自己不知道strcpy函式的引數型別吧。
範本2：unknown_function(nfoo) vs unknown_function(foo)
匈法在這裡有什麼收益呢？我看不到。對於乙個不知道確定型別的函式，程式設計師應該去檢視該函式的文件，這是一種成本。使用匈法的唯一好處是看**的人知道這個函式要求乙個整型引數，這又有什麼用處呢？函式是一種介面，引數的型別僅僅是介面中的一小部分。諸如函式的功能、出口資訊、執行緒安全性、異常安全性、引數合法性等重要資訊還是必須查閱文件。
範本3：nfoo=nbar vs foo=bar
匈法在這裡有什麼收益呢？我看不到。使用匈法的唯一好處是看**的人知道這裡發生了乙個整型變數的複製動作，聽起來沒什麼問題，可以安心睡大覺了。如果他看到的是nfoo=szbar，可能會從美夢中驚醒。且慢，事情真的會是這樣嗎？我想首先被驚醒的應該是編譯器。另一方面，nfoo=nbar只是在語法上合法而已，看**的人真正關心的是語義的合法性，匈法對此毫無幫助。另一方面，乙個優秀的書寫者會自覺地遵從乙個法則：**最小組織單位中的臨時變數以一兩個為宜，如果超過三個就應該重新組織。結合前述第乙個法則，可以得出這樣的結論：易於理解的**本身就應該是易於理解的，這是**的內建高質量。好的命名規範對內建高質量的助益相當有限，而壞的命名規範對內建高質量的損害比人們想象的要大。
三 匈牙利命名法的實施
這裡要證明匈牙利命名法在c語言是難以實施的，在c++語言中是無法實施的。從邏輯上講，對匈法的收益做出否定的結論以後，再來論證匈法的可行性，是畫蛇添足。不過有鑑於小馬哥曾讓已射殺之敵死灰復燃，我還是再踏上一支腳為妙。
前面講過，匈法是型別系統的冗餘，所以實施匈法的關鍵是我們是否能夠精確地對型別系統進行複製。這取決於型別系統的複雜性。
先來看看c語言：
1.內建型別：int,char,float,double 複製為 n,ch,f,d？好像沒有什麼問題。不過誰來告訴我void應該怎麼表示？
2.組合型別：array,union,enum,struct 複製為 a,u,e,s？好象比較彆扭。
這裡的難點不是為主型別取名，而是為副型別取名。an表示整型陣列？sfoo,sbar表示結構foo，結構bar？ausfoo表示聯合結構foo陣列？累不累啊。
3.特殊型別：pointer。pointer在理論上應該是組合型別，但是在c語言中可以認為是內建型別，因為c語言並沒有非常嚴格地區分不同的指標型別。下面開始表演：pausfoo表示聯合結構foo陣列指標？ppp表示指標的指標的指標？
噩夢還沒有結束，再來看看型別系統更阿為豐富的c++語言：
1.class：如果說c語言中的struct還可以用stru搪塞過去的話，不要夢想用cls來搪塞c++中的class。嚴格地講，class根本就並不是乙個型別，而是創造型別的工具，在c++中，語言內建型別的數量和class創造的使用者自定義型別的數量相比完全可以忽略不計。stdvectorfoo表示標準庫向量型別變數foo？瘋狂的念頭。
2.命名空間：boostfilesystemiteratorfoo，表示boost空間filesystem子空間遍歷目錄型別變數foo？程式設計師要崩潰了。
3.模板：你記得std::map型別的確切名字嗎？我是記不得了，好像超過255個字元，還是饒了我吧。
4.模板引數：template const t& max(const t& a, const t& b, binarypredicate comp) 聰明的你，請用匈法為t命名。上帝在發笑。
5.型別修飾：static,extern,mutable,register,volatile,const,short,long,unsigned 噩夢加上修飾是什麼？還是噩夢。
你願意做鐐銬上的舞者嗎？
除此之外，國外也有不少人討論這個問題。請看這裡
C語言變數和函式命名規範
c 語言變數和函式命名規範 關於c語言變數和函式命名規範 據考察，沒有一種命名規則可以讓所有的程式設計師贊同，程式設計教科書一般都不指定命名規則。命名規則對軟體產品而言並不是 成敗悠關 的事，我們不要化太多 精力試圖發明世界上最好的命據考察，沒有一種命名規則可以讓所有的程式設計師贊同，我們不要化太多...
C語言變數和函式命名規範
c語言變數和函式命名規範 關於c語言變數和函式命名規範 據考察，沒有一種命名規則可以讓所有的程式設計師贊同，程式設計教科書一般都不指定命名規則。命名規則對軟體產品而言並不是 成敗悠關 的事，我們不要化太多精力試圖發明世界上最好的命據考察，沒有一種命名規則可以讓所有的程式設計師贊同，程式設計教科書一般...
C語言變數和函式命名規範
c 語言變數和函式命名規範 關於c語言變數和函式命名規範 據考察，沒有一種命名規則可以讓所有的程式設計師贊同，程式設計教科書一般都不指定命名規則。命名規則對軟體產品而言並不是 成敗悠關 的事，我們不要化太多 精力試圖發明世界上最好的命據考察，沒有一種命名規則可以讓所有的程式設計師贊同，程式設計教科書...