在一個項目組里面，經常會互相review同事的代碼，review的過程中相信會產生不少矛盾，這篇文章記錄一下我對代碼review的一些看法。首先是編碼規(guī)范的問題，拿PHP來說。比如命名規(guī)范，indent之類的。這些都應該在項目編碼開始之前大家立好規(guī)矩。是采用駝峰命名法還是用下劃線分割單詞，indent?是用tab還是用空格，大括號是換行:

function foo() {
}

還是不換行：

function foo() 
{
}

這些最基礎格式規(guī)范一定要在最開始寫在一個wiki文檔上，項目組所有成員都需要熟記這個規(guī)范。這種規(guī)范，兩上個技術骨干定一下就好了，定下來就按它執(zhí)行。這個東西其實只要統(tǒng)一就好，無需糾結，孰好孰壞也并不影響項目質量。

接下來我說一下我對關于一些實現(xiàn)邏輯的寫法review的個人理解，比較經典的是關于 if...else...?的用法的討論。如果一個函數(shù)中用if...else來做分支處理，代碼如下：

if($flag = 1)
{
    .....
    $result = 'A';
}else if($flag = 2) {
    .....
    .....
    $result = 'B';
}else {
    .....
    .....
    $result = 'C';
}

.....
.....
return $result;

這種情況，如果if...else語句下面的處理跟邏輯跟結果A或者B沒有什么關系的話 ，可以改寫成如下代碼，使得代碼邏輯更加清晰

if($flag = 1)
{
    .....
    return 'A';
}
if($flag = 2) {
    .....
    .....
    return 'B';
}
.....
.....

.....
.....
return 'C';

簡單一句話就是，適當?shù)娜サ鬷f...else而換成if return結構，很多時候可以提高程序的可讀性，但也不能認準這個死道理，比如下面這段（形式A）代碼

    function foo($flag) {
        if($flag) {
            $var = 'A';
        }else {
            $var = 'B';
        }

        ....
    }

我的同事review的時候建議改成如下（形式B）：

    function foo($flag) {
        $var = 'B';
        if($flag) {
            $var = 'A';
        }
        ....
    }

這其實并沒有意義，首先這并沒有增加程序的可讀性，其次形式A的代碼其實更符合人類的思維，它表述出$var變量非A既B的邏輯，而下面的代碼表述的是$var變量的默認值是A，當flag為true的時候它被賦值B，給人一種它可能還會有其他情況被賦值為C、D ... 之類的值的預期。

所以在review代碼的時候不能教條（簡單的認為只要去掉else代碼就會變得更簡單易讀），review需要關注的點應該是是否有邏輯漏洞，潛在BUG，非常小可能性出現(xiàn)的異常沒有處理。而對于代碼的表述方式，不應該過多關注。所以反之若是有人寫了形式B的代碼，也沒有必要在review的時候，讓他改成形式A。如果review的這么仔細，不但不會提高代碼質量，反而會大大減慢項目的開發(fā)進度，增加溝通成本。

所以，review這件事，要有度！