程序命名的一些提示

選擇一個正確的名字是編程中最重要的事。以前酷殼向大家推薦過兩篇文章《編程命名中的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”, 等等。 本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/haoel/archive/2010/04/08/5461669.aspx