程式命名的一些提示

一個正確的命名可以讓你更容易地理解程式碼的程式，好的命名可以消除二義性，消除誤解，並且說明真實的意圖，甚至可以讓你有清新的氣息以讓你更能吸引異性。;-)

方法，類和變數

正確的名字可以讓你的程式顧名思義，下面是一些提示：

不要使用”ProcessData()“這樣的命名

你如果在你的程式生涯中使用這樣的函式名，那麼這意味著你將是一個不合格的程式設計師而會被淘汰或解僱。請明確實際的功能。比如：ValidateUserLogin（驗證使用者登入） 或 EliminateDuplicateRequests（去除重複請求） 或 ComputeAverageAge（計算平均年齡），等等。

讓命名來幫你設計程式

讓我們假裝有這麼一條規則是——“任何的函式是有輸入/輸出的”，那麼，你需要思考的是所有的把input變成ouptut的步驟，然後，你可以選擇一個簡短的句了來說明你的這段程式，然後，把這個短句再精練一下，最終成為你的函式名，而那個短句則成了你程式的結構。

命令不應該是模糊的

如果你有一個類名叫：FilterCriteria ，但實際上其可用於檔案過濾，那麼這個類應該叫做： FileFilterCriteria ，就算是你真要想要用 FilterCriteria，那它也應該是抽象類。

避免過多的工作

這只是一個風格上的事情，但還是需要注意一下。在上面，我們使用到了 ValidateUserLogin 和 EliminateDuplicateRequests兩個名字，這兩個命令看上去需要做很多比較複雜的事。所以，讓你的名字變簡單一些也有利於你的程式更容易閱讀和維護。一個軟體本來就是由不同的模組拼成，而一個模組又是由更細小的函式和類拼成。程式設計中，我們都知道，一個函式的尺寸應該控制在200行以內，一個類的介面應該控制在20個以內。所以，從其名字上我們就不要讓一個名字取得太大了。

避免類名以 “Manager” 結尾

這樣會讓你類變成一個黑盒子，當然，有一些程式設計師喜歡使用這樣的名字讓那個類看起來好像更強大一些，但其實這樣並不好。一般來說使用Manager這個字眼通常是使用工廠模式，或是一個容器，所以，對於一些最基本的演算法或是資料結構的封裝，最好是在其名字上體現這一演算法或資料結構的名字，如： SortedList 和ConnectionPool 。

為你的列舉型別使用單數名字

一個列舉型別會列出所有可能的值，所以，叫animalType 會比 animalTypes 要好。

匈牙利命名應該更多的關注名字的含義而不是型別

匈牙利命名是一個以前很流行的命名方法，其給出了一整套的方法告訴你如何標記你的變數的型別，但可惜的是很多程式設計師過多的關注了變數了型別，而不是變數名的含義。而變數名的含義才是根本。

不要讓名字隱藏了內在

比如，我們有段程式碼需要處理使用者的輸入，把其轉成UTF-8碼，然後標準化（比如一些協議），最後再處理相應的跳脫字元。千萬不要把這函式命名為Escape() ，因為你需要呼叫 ToUTF8() 以及NormalizeEntities() 最後才是 Escape() 函式。如果你希望使用一個函式名來做這三件事，那麼，你寧可使用一個模糊的名字再加上充分的註釋，而不是一個確切的名字。模糊的名字會讓別人在閱讀時想進去看看，而確切的名字則會讓別人在閱讀程式碼時忽略細節（這看起來和第一點有點矛盾，其實也是為了程式的易讀）。比如：ProcessUserInput()

一致性, 一致性, 一致性

強調文章和程式碼的一致性，就算是文件寫得再詳細，我們也要去讀程式碼，所以文件主要是體現思路和反映需求和設計。在程式上，我們的命令應當和文件中的術語保持一致，而程式中的命名也應該是用和文件相同的風格，這樣，我們可以少很多理解上的成本。

不要害怕改名

有一些時候，你會覺得某具名字不合適，你需要改動一下。但你馬上發現要改這個名字，需要修改很多的程式程式碼。在這裡有一個原則，如果你的這個名字不是以API的方式釋出時，那麼你就應該不要害怕更改名字，就算是修改的工作量並不小，為了日後的更容易的閱讀和維護，這是值得的。但是，如果這是一個API的名字，那我還是建議你不要改了，就算是你覺得這個名字爛得很。因為，當你的程式以API的形式釋出後，會有N多的他人的程式依賴於這個名字，這個時候，相容性和使用者比什麼都重要。

Frameworks 和 Libraries

你的使用者是一個程式設計師，他需要使用你的程式碼進行二次開發。 Namespaces 將會是你重點需要注意的東西。

使用namespaces 而不是類的字首

希望你的程式設計序語言支援namespace，這樣，你就可以使用它而不是在類名前面加字首了。如果你所使用的語言不支援namespace，那麼你應該上網看看其它程式設計師使用什麼樣的方式來區分自己的程式碼和別人的程式碼名字空間。

使用普通的namespace而不是使用公司名

使用公司名做namespace並不是一個好的相法，因為公司名很容易變更，比如，公司因為被收購，被控告，合併，重組等原因需要更名。產品的名字同樣也會改變。所以，使用一個普通的namespaces會好一些。如STL，ACE等。

資料庫

Database Schemas 意為資料模型，所以，其名字應該和其領域是合乎邏輯的，而不是為了程式設計的方便。

資料表應使用複數

別使用單數形式，這是因為在遠古的ORM 中需要使用單數的形式來定義類名。而且，一個表中包含了許多行資料，所以也應該是複數的。如，”items“, “customers“, “journalEntries” 等等。,

為那些包括派生資料或是日常處理的表使用aux_ 和meta_ 字首

這些表中的資料都是用來做為臨時處理的，所以，你需要一個字首或是字尾來使他們區別於實際的表。

為主鍵加入表名

如果你有一張表叫 “driverLicenses” 而ID 列是主鍵，那麼你應該把這個主鍵命名為”driverLicense_id” 而不是”id”。這樣做的好處是，當你在連線兩個表的時候，你不需要為主鍵指定表名，如： “driverLicense.id” 或”vehicle.id“，也不需要為其取別名。

使用字尾來標識類

這樣的例子很多，比如：ISBN 和Dewey Decimal numbers，VIN等等.

Joe Celko有一篇文章叫 SQL Programming Style提到了下面這樣的風格：

_id 主鍵

_nbr 字串型的數位（有嚴格的規則，如：車牌號，身份證號，手機號等）

_code 標準化編碼(如：郵編，ISO 國家編碼)

_cat 種類名

_class 子集

_type 稍不正式的類名，比如，駕照中的，”摩托車”, “汽車”, and “計程車” 型別。

其它

對於“物理上”的東西，命名其是什麼，而不是做什麼

比如某些物理上的名字，姓名，性別，檔案路徑，網路連結，檔案描述符，下標索引，類的屬性，這些都是物理上的東西，所以，其名字應該是標識其是什麼，而不是用來做什麼。

對於“邏輯上”的東西，命名其做什麼，而不是是什麼

比如某些邏輯上的名字，函式名，資料結構，等。

避免”Category” 問題

千萬別使用”Category” 作為你的屬性名，因為，你會馬上發現，這並不靠譜，因為這就等於什麼沒有說。與此相類似的還有”type” ，”kind” ，”variant” ，”classification” ，”subcategory” 等，對於這些名字，沒人知道其是什麼東西。而應該使用更為明確的分類，如： “FuelEfficiencyGrade”, “PackagingType”, “AgeGroup”, “Flamability”, “AllergenLevel”, 等等。