做爲一名開發人員，在編碼過程當中，你總會花不少時間來思考如何正確命名。由於名稱無處不在，你須要考慮文件名、類名、方法名和變量名。php
雖然咱們須要花費不少時間，可是爲了更好的命名仍是值得的。本文我將向你介紹幾個可以幫助你編寫優質命名的簡單規則。命名這件事自己也是一門藝術。web
使用顯示意圖的名稱
名稱直接顯示意圖這件事提及來容易作起來難。你是否常常遇到一些難以判斷其用途的名稱？編程
一個好的經驗法則是：若是一個名稱須要註釋，那麼它自己就是不能說明意圖的。微信
這個代碼片斷就演示了一個不能顯示意圖的變量命名。app
<?php
private $s; // Time in seconds
變量$s什麼也說明不了。它沒有任什麼時候間流逝的感受，咱們最好是能選擇一個名稱指定測量內容和測量單位。下面這些變量名看起來就好不少。編輯器
<?php
private $days_since_creation;
private $elapsed_time_in_seconds;
private $seconds_since_last_modified;
選擇一個能夠顯示意圖的名稱能使一段代碼更容易理解，從而下降維護成本。雖然選擇的過程會花費一些時間，但這是爲了節省更多的時間。咱們來一塊兒看看下面這個例子。函數
<?php
function getList() {
$list1 = [];
foreach ($this->the_list as $x) {
if ($x % 2 != 0) {
$list1[] = $x;
}
}
return $list1;
}
function getOddNumbers() {
$odd_numbers = [];
foreach ($this->numbers as $number) {
if (isOdd($number)) {
$odd_numbers[] = $number;
}
}
return $odd_numbers;
}
你能立刻說出 getList 函數的做用嗎？恐怕須要看完具體實現以後才能說出來吧。而這段代碼自己沒有什麼複雜的邏輯，一共3個變量和不到10行的邏輯。ui
接下來咱們再來看看 getOddNumbers 這個函數，有沒有發現，它的邏輯和 getList 實際上是同樣的。而且沒有更加代碼的複雜性，變量數量相同，代碼嵌套層級也相同，惟一不一樣的是代碼寫的更加清晰了。但你卻能夠經過函數名一眼看出這個函數的做用。this
經過上面的例子咱們發現，只須要在命名上作一些小小的改變，就可以輕易的告訴別人你的代碼的做用。編碼
避免虛假信息
你應該避免留下一些可以掩蓋代碼真實意圖的錯誤線索。
你應該避免使用一些有歧義的單詞，例如不要把產品集合命名爲 productList，除非它自己就是一個 List 類型的對象，這有可能會誤導別人，更好的名字應該是 products。
命名中千萬不要使用大寫的 o 或者小寫的 L 由於它們看起來就像0和1同樣。
對於相近的名稱也要當心使用，例如，你讓你來分辨 SomeMethodForEfficientHandlingOfFiles 和 SomeMethodForEfficientStorageOfFiles 這兩個單詞時，你須要用多長時間，我相信大多數人第一眼看上去，就認爲它倆徹底同樣。
作出有意義的區分
數字序列的命名不是命名的好方法，這樣的名字是沒有任何意義的，也不可以展現出做者的意圖。
咱們來看一下這個例子
<?php
public function duplicateArray($arr1, &$arr2) {
foreach ($arr1 as $key => $value) {
$arr2[$key] = $value;
}
}
這段代碼中，若是咱們用 $source 和 #destination 來代替 $arr1和 $arr2 會更好。
使用你知道發音的名稱
若是大家不知道名字的發音，那麼你和人交流起來就會像白癡同樣，這就很麻煩，畢竟社交是編程中比較重要的一個環節。你的命名最好是每一個人都可以經過發音就立刻就能想到的單詞。
假如咱們有一個變量命名爲 $xsq 而且這在公司內是一個很重要的變量，想象一下你平常和同事的對話：
"Hey, what about that variable eke ess kjew?"
"You mean the access queue?"
有些開發者會嘗試把變量湊成一個單詞的發音，而有些開發者則會選擇讀單詞的字母拼寫。
使用便於搜索的名稱
由一個字母組成的名稱的很差之處在於難以定位。數字常量也有一樣的問題，因此咱們在開發過程當中須要把魔數替換爲常量。在代碼裏搜索數字8是一件很困難的事情，可是若是你搜索常量 MAX_BLOCKS_DISPLAYED 就會簡單不少。單字母命名的惟一用例是在簡短方法中的局部變量。
成員屬性前綴
不要使用成員屬性前綴。
有些開發者習慣把類中全部的私有變量用下劃線爲前綴命名。不要這麼作，你應該保證的是，你的類和方法要足夠小，以致於你不須要使用這些前綴。
或者，你可使用IDE（或安裝插件）來根據變量的使用範圍給變量着色。
把你的代碼想象成一個露營地，讓它儘量的保持整潔。
總結
以上，就是建立有意義命名的一些原則和方法。有任何問題歡迎給我留言，本文靈感來源於《代碼整潔之道》，推薦你們都讀一下這本書。
原文結束了，我我的仍是比較承認做者的觀點的，代碼中的各類命名仍是要花時間去琢磨琢磨的，這裏也分享一下我在工做中經過 code review 的一些小感悟吧。在代碼中，文件名、類名、方法名，這些不要嫌長，要儘量的達意，而且可讀。而對於一些局部變量，則能夠適當放寬限制，若是太長的話會致使代碼中有不少沒必要要的換行，可是也最好不要出現 a1 、 a2 這樣的命名。由於這種是徹底不能理解它表明什麼的。
這篇文章在 medium 上收穫的 3k+ 的 claps。因此就想着翻譯過來推薦給你們，同時也推薦你們讀一讀《代碼整潔之道》。
本文分享自微信公衆號 - 代碼潔癖患者（Jackeyzhe2018）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。