There are only two hard things in Computer Science: cache invalidation and naming things.
節後第一天,無心敲程式碼,隨意聊聊命名這件事吧。(別問為什麼不聊快取失效,問就是不會)
對於大多數碼農來說,命名確實是一個很大的難題。我們往往會花費很多時間在命名上,一個好的命名對於程式碼可讀性提升的幫助是巨大的。
一、遵循規範
一個優雅的命名必定是嚴格遵循一定的規範的,這個規範既指行業通用規範也包括公司團隊內部的規範。不符合規範的命名對於程式碼可讀性的破壞力是巨大的。
zhuanhuanweiriqi //拼音命名,不符合規範
convertstandardtermtodate //全部小寫,不符合規範
convertStandardTermToDate //採用小駝峰命名複製程式碼
上面的幾個命名錶達了同一個意思,但是很顯然前兩個命名如果出現在我們的程式碼中無疑是一場災難,最後一個採用了小駝峰命名對於程式碼可讀性的提升則是顯而易見的。
二、表意清晰
命名最基本也最重要的一點就是表意要清晰。每一個變數、方法都應該能夠見名知義。在小白程式的程式碼中經常會看到list1,list2,fun1,fun2
這樣的命名。這樣的命名在專案或者頁面內容較少的時候也許還能勉強閱讀。但是會極大的降低程式碼的可擴充套件和可維護性。
但是還有一種情況下會給我們命名帶來困擾,比如我們在使用者管理中最常見的幾個命名問題:userList
和users
都可以用來表示使用者列表;getUsers
和getUserList
都可以用來獲取使用者列表;getUserById, getUserInfoById, queryUser, ...
。當我們遇到這種多個命名意義相近的無法取捨的時候,我們需要做的事情就又回到了第一點,讓專案團隊約定其中一種命名方法並且統一地運用到所有模組。
三、功能的合理拆分
通常,如果我們想不到一個合適的命名或者命名過長,這意味著我們的程式碼裡一定出現了不合理的設計。比如goOutToPlayFootball
顯而易見的可以被拆分成goOut
和playFootball
兩個更單一的方法,這樣做的好處是不言而喻的,既簡化了命名增強了程式碼可讀性,又降低了耦合度,還提高了程式碼的可擴充套件性。
四、整合工具類
我們經常需要是實現一些功能相近的方法,比如日期相關的一些方法,我們就可以建立一個名為dateUtil
的集合,把所有日期相關的方法放到dateUtil
內部去實現,比如數字格式化的方法可以放在numberFormatter
裡面等等。
結語
快跑題了,就此打住吧。
命名確實是一件挺難的事情,要在巨量的詞彙庫中挑選出一兩個詞來表達出最正確和具體的意思。但這也不是一件壞事,它可以迫使我們去思考我們的方法和元件到底要需要實現怎樣的功能。每一次命名都給了我們一次程式碼審查和優化的機會,我們要學會珍惜。
隨手寫了點自己的體會,權當拋磚引玉,大家可以一起交流下心得。你們對命名這件事又是怎麼看的呢?