酷殼：http://CoolShell.cn?

?

選擇一個正確的名字是編程中最重要的事。以前酷殼向大家推薦過兩篇文章《編程命名中的7+1個提示》?和《編程中的命名設計那點事》，今天再向大家推薦一篇。一個正確的命名可以讓你更容易地理解代碼的程序，好的命名可以消除二義性，消除誤解，并且說明真實的意圖，甚至可以讓你有清新的氣息以讓你更能吸引異性。;-)

方法，類和變量

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

• 不要使用”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”, 等等。

文章：來源

from:?http://blog.csdn.net/haoel/article/details/5461669

總結

以上是生活随笔為你收集整理的程序命名的一些提示的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。