編程命名中的7+1個提示
1.- 變量應該是盡可能的望文知意。千萬不要使用教材中的命名方式。
- 好的變量： daysDateRange, flightNumber, carColor.
- 壞的變量： days, dRange, temp, data, aux…
在我們的日常工作中，有很大數量的開發人員喜歡使用短的變量名，而不是有含義的變量名。這主要是因為我們大學教科書的那些示例所造成的，人都是先入為主，所以，教科書中的那些很抽象，帶著演示的變量命名影響了我們一代又一代的程序員，并影響了他們很多年。雖然那些短的，教材式的變量名，可能會讓你少打一些字，但其實，這是非常非常不好的。因為軟件的維護成本遠遠大于了軟件的開發成本，如果你不取一個好的一點的變量名，那么當進行代碼評審時，當進行bug fixing時，當進行代碼重構時，當進行代碼維護時，你的某個變量名可能會讓你一頭霧水，不知道所措，還可以會讓你走入陷阱，造成更大的時間成本。所以，一個可閱讀的代碼必然和那些不錯的變量名分不開，而這也能讓你的軟件間接上有更好的質量。
2.- 變量名不要太長，盡可能地簡短
只有簡單和簡短的變量名才是容易閱讀的。因為你的變量名一定會用于程序語句中，所以，為了讓你的程序語句看起來的簡短，你的變量名也應該短一點，不然寫出來的一個表達式就會顯得很復雜。
當然，在有些時候，一個有含義的變量名和一個簡短的變量名可能存在一些沖突。這相當鍛煉我們的語言能力——如果有最精煉的詞語來表達最豐富的含義。如果實在做不到，那么，取一個有含義的變量名要比取一個簡短的變量名更好一些。不管怎么樣，我們希望即簡短又有豐富的含義，但如果不能兩全，那有含義優先級更高一些。
- 壞的變量：howLonDoesItTakeToOpenTheDoor， howBigIsTheMaterial…
- 好的變量：timeToOpenTheDoor， MaterialSize.
3.- 可以使用縮寫，但需要有一些注釋
有一些時候，我們需要使用一些縮寫來命名變量，比如：用usr來表示user，用gp來表示group，用conf來表示configuration，用cwd來表示current working directory，用ptr來代碼point to reference，等等，等等?？s寫一般要用在大家可以看得懂的，而不是為了縮寫而縮短一個單詞，當然，如果你把縮寫后的變量名加上注釋，那就更加穩妥了。關于一些約定俗成的縮寫，可參看本文的附錄一。
4.- 使用合適的匈牙利命名規則
這里有一篇非常不錯的英文文章告訴你 《什么是合適的匈牙利命名 》，這篇文章同時還告訴你如何去用他?；旧蟻碚f，匈牙利命名法主要是為變量加上某種前綴以標識這個變量的類型，或是一種方法的功能。其基本原則是：變量名＝屬性＋類型＋對象描述。
比如：在描述類型方面：指針p，函數fn，長整型 l，布爾b，浮點型（有時也指文件）f，雙字 dw，字符串 sz，短整型 n，雙精度浮點 d，無符號 u……等等。關于更多的命名規范，請參見附錄二。
注意，匈牙利命名也是有不好的地方的，比如你要把一個整形改成一個浮點型，你除了要改變這個變量的類型，你還要改變這個變量的名字。這是相當麻煩的。而且，在某些時候，這種前綴式的命名可以反而讓你不知所措。另外，在C++中，有了類以后，這種命名方法就顯得不容易去實施了。所以，合適地使用匈牙利命名方式背后的思想是很關鍵的。
5.- 不要使用反邏輯來命名
- 好的命名： IsEnabled.
- 壞的命名： IsNotEnabled.
在閱讀的時候，我們更喜歡正向的邏輯，而不是反向邏輯。這一規則不單單的命名，在條件語句中，我們也是要盡量不要使用這種反面的邏輯。如：if (! (isAdmin || isUser))，這樣的語句很不符合人讀代碼的習慣，寫成這樣會更好一些——if (!isAdmin && !isUser)。
6.- 保持一致性
保持所有代碼的一致性。使用相同的命名規則。這外世界上沒有最好的命名規范。但有一點是可以確認的，那就是在一個代碼庫中，應該使用一致的命名規則，即使這個規則不那么好，但整個團隊使用一致的就是好的。
7.- 附和應用程序的領域術語
在不同的領域中，不同的觀念會有非常特別和不同的意思。例如：單詞“order”并不總是意味著“次順”，有些時候，其意味著“訂單”，有些時候，意味著“命令”，有些時候，意為著“規則”。所以，在某個領域中，某些單詞會有不同的含義，所以，這需要我們的命令去附和這些領域。
黃金法則- 花一些時間去思考去權衡一下你的變量名
當你設計好一個的變量名一個函數名的時候，別著急去使用他，停下來，想一想，這個變量名是否合適，是否還有更好的？也許你正在使用的是一個很不好的變量名。有些時候，需要我們權衡利弊一下，可能還要去和同事討論一下。
總之，變量名是編程的第一步，第一步走好了，后面才走得好。試想，無論是你或你的同事在使用一些好的變量名編程是一件多么輕松的事啊。