1. 統(tǒng)一的編碼規(guī)范

編碼規(guī)范往簡單說其實就是三個方面：

換行

空格

變量命名

放在 PHP 里面，還有一些附加的地方，比如關(guān)鍵字大小寫，語法糖的使用

（array()與[]等）的問題。之前整理過 PSR 的標(biāo)準(zhǔn)，也找過 php-cs-fixer 這樣的工具。

這些都是規(guī)范代碼的重要手段。有統(tǒng)一的標(biāo)準(zhǔn)，

配合上工具的檢查，形成統(tǒng)一的編碼約束不是什么難題。

沒有規(guī)范，不同的人甚至同一個人在空格、換行和命名上

都有可能是十分隨意的。代碼一長，回使整個文件看起來無比雜亂。

典型的例子比如：if和else的組合，可以寫出無數(shù)種風(fēng)格，比如：

# 單語句不寫大括號 if (true) doSomething(); # else 大括號換行 十分占篇幅 if (true)

{

? ? doSomething();

}else {

? ? doElseThings();

}

# 此外還有關(guān)鍵字后不帶空格，隨意縮進(jìn)等等 # ...

再比如變量函數(shù)命名的問題上，各種混搭風(fēng)格層出不窮：

# 全小寫 $someparam1 = null; # 首字母下環(huán)線 $_some_param_1 = null;?

# 某些庫的類，下劃線和大小寫混用 class Abstract_ClassA{

}

這里并不探討各種寫法的優(yōu)缺點，只是風(fēng)格需要保持統(tǒng)一，不要混用。

2. 良好的編碼習(xí)慣

如果你仔細(xì)看過 PSR 的標(biāo)準(zhǔn)，可能也會注意到某些地方其實是標(biāo)準(zhǔn)無法涉及到的。

比如一個超長的表達(dá)式在什么時候換行，如何縮進(jìn)等。

這里涉及到的就是編碼習(xí)慣的約束問題。

比如方法的鏈?zhǔn)降恼{(diào)用的問題，比如某些數(shù)據(jù)庫查詢的封裝：

# 不換行的情況下句子會很長 $result = $this->db->select('id')->where('a', 1)? ?

?? ? ?->groupBy('a')->orderBy('id', 'DESC')->result(); # 這種情況下我建議

是一個條件一行，保持縮進(jìn) $result = $this->db->select('id')

? ? ->where('a', 1)

? ? ->groupBy('a')

? ? ->orderBy('id', 'DESC')? ??

? ? ->result();

還有數(shù)組定義，某些數(shù)組成員字符串很長的情況下的寫法：

$array = ['abcdefg', 'acbdfeg', 'bcadgfe', 'cdadgef']; #?

如果成員太長，我建議拆解，這樣 $array = [

? ? 'abcdefg',? ??

? ? 'acbdfeg',? ??

? ? 'bcadgfe',? ??

? ? 'cdadgef',

];

3. 尋找最優(yōu)的寫法

寫代碼的過程中，最優(yōu)的寫法和編碼習(xí)慣又不是同一件事情。這里要說的指的是

如何遵循 PHP 的語言特性或者框架的特征，充分發(fā)揮語言和框架的能力來減少冗余。

比如在獲取前端傳入的參數(shù)的時候，很多時候能見到這樣的代碼：

$param = isset($_POST['param']) ? $_POST['param'] : '';

更有甚者一些框架將前端傳入的參數(shù)封裝了一層，比如

$this->request->data['param']，如果再去用isset或者array_key_exists判斷，

整個獲取參數(shù)的語句就會變得很長。

某些情況下使用三元運算符的時候需要注意?:是可以合并使用的。

其實我們應(yīng)該去嘗試封裝這種寫法，防止同樣的變量出現(xiàn)在一個語句中多次的情況。

對于默認(rèn)值的賦予，可以調(diào)研框架是否有封裝提供，或者通過強(qiáng)制類型轉(zhuǎn)換的方式進(jìn)行。

還有一種情況是條件和循環(huán)嵌套的時候。比如從數(shù)組里抽取某一個字段，

或者對某一個字段的值進(jìn)行處理的時候，善用array_map以及引用（&）

往往能節(jié)省不少工作量。但是使用的時候也要注意數(shù)組指針最后的位置。

在根據(jù)條件返回結(jié)果時，需要善用return。還有就是合理的抽象與封裝。

4. review 自己的代碼

除了以上提到的在日常開發(fā)中需要注意的一些問題。還有就是事后的工作。

我相信很多人在看自己以前的代碼的時候都有一種其實有更好的寫法的感覺。

隨著時間的推移自己總會有更豐富的閱歷，更多的想法。偶爾 review?

自己的代碼也是對過去的總結(jié)，也許會有新的感知。

5. 推廣給你的隊友

團(tuán)隊項目中，隊友的配合對整個代碼的規(guī)范起著決定性的作用。

一個團(tuán)隊中有一個人不遵守規(guī)范，而又要到處修改代碼的時候，

很快就能破壞到所有的約束。

有統(tǒng)一的標(biāo)準(zhǔn)，有良好的執(zhí)行力才能完成這件工作。

本文來源：https://www.fushouyu.com/shouyou/205.html