開發經驗漫談 -- 編碼規範

這幾期想和大家分享下我自己在開發時的一些經驗，這次來說說關於代碼規範。

什麼是代碼規範

我理解的代碼規範，是一個標準，讓寫代碼的人按照這個標準來開發。

例如php的psr1（https://www.php-fig.org/psr/psr-1/）和psr2（https://www.php-fig.org/psr/psr-2/）

為什麼需要代碼規範

萬事萬物必然有其存在的意義，這裡說下我的理解：

1. 這裡先說明很重要的一點，那就是代碼是寫給人看的，並不是機器，所以說代碼要讓別人好理解。
2. 我們多數情況下都是團隊開發，所以大家都約定好一個標準，更加有利於團隊代碼的可維護性。
3. 團隊中有老人離職、有新人加入，從代碼規範中是可以看到這個團隊的文化的傳承的。
4. 對自己也是個約束，不要太隨意了。

如何制定規範

制定步驟：

1. 首先看是否有官方規範。一些較新的程式設計語言通常會有自己的一些規範，例如Golang，大家可以參考官方的Effective Go（https://golang.org/doc/effective_go.html），建議遵守。
2. 其次看是否有權威的、認同度高的規範。通常使用較廣泛的語言會這樣做，如php的psr1、2，建議遵守。
3. 之後，才是我們團隊來制定自己的規範。

團隊規範注意：

1. 盡量避免一言堂。因為是團隊規範，所以是需要得到大家的認同的。
2. 要經常反思，不好的地方和團隊成員討論不斷調整。其實這也是要求團隊成員開發時不斷反思的一個過程。
3. 規範簡單易懂。

參與過的規範執行個體

這裡舉兩個自己參與過的執行個體：

Golang項目

我們團隊第一次使用Golang開發項目時，當時制定了這樣的一套規範：

• 變數

1. 多個詞之間用"_"（底線）串連，如：prj_home
2. 可匯出全域變數每個詞的首字母均大寫，如：Prj_Home
3. 包內部全域變數用“_”（底線）開頭，單詞小寫，如：_prj_home

• 函數

1. 函數名稱駝峰式，如：listPrj

• 類型

1. 類型名用“t”開頭，如：t_prj_item
2. 可匯出名稱用“T”，如：T_Prj_Item
3. 介面類型用“i”開頭，如：i_logger
4. 可匯出介面類型用“I”，如：I_Logger
5. 多名詞規則同“變數命名規則”

當時制定這套規範時，我們對Golang的使用還是剛剛起步，很多不理解的地方，所以這套規範現在看來，很多地方都不合適，但在當時，還是起到了很大的作用。

1. 這套規範協助我們這些初學者在當時統一了風格，避免了混淆。
2. 後續的同學也能很快理解當時的項目，所以項目雖早，但現在也很好的運行著。
3. 隨著Go越用越多，我們不斷更新我們的規範，從命名上，項目的組織上，都一直經曆著變化，目前最新可參考gobox項目代碼（https://github.com/orgs/goinbox/dashboard）

PHP項目

這個項目也是我們團隊的一個編碼規範的典型運用，規範如下：

• 綜述

對於psr標準中已規定的部分，請遵照執行，這裡不再贅述。
這裡主要定義現有psr標準中未規範的部分。

• 變數

統一使用駝峰式

• 數組key

使用底線分隔多詞

• 判斷時常量在等號左邊還是右邊

統一放在等號右邊

if ($a === 0){}

• 函數中參數如果提供預設值，等號兩端是否有空格

有

function foo($a = 0){}

這個項目的編碼規範由當時我們團隊的五個人共同制定，我們列出psr中未規定的部分，每個人陳述自己的觀點，然後舉手錶決。

結束語

規範不是目的，只是一種手段，好的規範十分有助於編程人員培養良好的編程習慣。

最後，請記住一點：代碼是寫給人看的，機器只需要0和1。