Laravel5.5開發規範 [ 個人總結 ]
我先在石墨文件總結的這篇開發規範，感覺在石墨文件的排版看著更舒服，點選傳送：Laravel5.5開發規範
一、概述
laravel5.5是目前laravel框架發行使用最穩定的版本，laravel社群會維護這個版本到2019年6月，所以公司一直採用laravel5.5版本作為所有專案的開發框架。
為了保證產品開發過程中統一程式碼的編寫原則，提高程式碼的可讀性、可維護性及可靠性，特定此開發標準規範。
請所有新老員工嚴格按照此文件制定好的程式碼規範來進行開發。
二、開發環境
1. PHP開發環境
- 作業系統：windows/Linux
- 資料庫：Mysql5.7
- PHP：PHP7.0+
- 伺服器：Nginx1.0+
- 檔案編碼要求：utf-8 無 BOM頭
2. 伺服器環境
- 作業系統：Linux（centos7.2+）
- 資料庫：Mysql5.7+
- PHP：PHP7.0+
- 伺服器：Nginx1.0+
三、命名規範
1. 目錄和檔案命令
- 目錄使用小寫字母，如果單個字母無法滿足要求，使用中劃線連線多個字母，如：easywechat-composer；
- 類庫、函式檔案統一以 " .php " 為字尾；
- 類的檔名均以名稱空間定義，並且名稱空間的路徑和類庫檔案所在路徑一致；
- 類檔案採用首字母大寫駝峰命令，其他檔案統一採用首字母小寫駝峰命名。
2. 類、函式、屬性、變數命令
- 類的命名與類檔名一致，採用駝峰法（首字母大寫），例如UserController應該直接命名為User；
- 函式的命名使用駝峰法（首字母小寫），例如 getUserName；
- 屬性、變數的命名使用駝峰法（首字母小寫），例如 tableName、instance；
- 以雙下劃線“__”打頭的函式或方法作為魔法方法，例如 __call 和 __autoload。
3. 常量和配置命名
- 常量以大寫字母和下劃線命名，例如：APP_PATH、THINK_PATH；
- 配置引數以小寫字母和下劃線命名，例如：url_path。
4. 資料表和欄位命名
- 資料表和欄位採用小寫加下劃線方式命名，並注意欄位名不要以下劃線開頭，不允許使用駝峰和中文作為資料表字段命名；
- 優先採用簡短易懂的英文加下劃線命名，例如：member_info，過長時使用簡寫或前4個字母；
- 如果該欄位表示的是時間，則統一使用_time為字尾。例如：add_time、edit_time；
- 會員ID欄位命名統一使用uid來命名，請勿使用userid、user_id等；
- 日期型欄位，必須使用timestamp型別，預設值為'0000-00-00 00:00:00'；
- 程式碼中的sql語句，禁止物理刪除，用欄位進行標記（如：is_del或者status）。同時資料庫也會禁用刪除許可權；
- 狀態欄位統一使用名稱：status，預設0為不可用，1為正常；
- 建議資料表的命名不使用字首設計，表字首其實已經是一種過時的設計了，很多時候跨庫的設計比表字首的設計來的更靈活和實用；
- 除自增長ID外，其餘欄位、表都應加上說明註釋，在註釋時，如果該欄位表示多個狀態應在註釋處補全說明；
- 習慣上來說，時間與狀態欄位統一放在表的最後邊，時間在狀態之前。
5. 介面引數命名
- 統一採用小寫字母；
- 如果有多個字母連線，採用 “ _ ” 進行連線，如：user_info；
- 如果單個引數過長，可以擷取單個單次的前4個字母。
四、目錄結構
五、註釋標準
方法函式必須註釋清楚用途，如需傳入與輸出資料的方法函式必須做到以下申明：該方法函式的用途、需要傳入的引數、傳入引數的型別、處理完後輸出的引數、輸出引數的型別。如下所示：
六、輸出標準
除了報錯或成功跳轉頁面輸出外，其餘部分，如：模型、類、公共方法等輸出格式統一使用以下的方式輸出：
/*
* status：布林型，輸出狀態；
* msg ：字串型，提示資訊；
* data ：輸出資料，根據實際需求，可以是陣列、字串、物件等。
*/
['status'=>Boolean, 'msg'=>String, 'data'=>'']七、跨行和空格
1. 跨行
- 方法註釋和方法之間不跨行；
- 兩個方法之間必須跨行；
- 方法內的if判斷前必須跨行；
- 方法內的foreach必須跨行；
- 方法內的程式碼需要按照邏輯塊兒進行跨行，如：資料準備塊、邏輯判斷塊，邏輯計算塊、輸出塊等；
- 方法的花括號必須跨行，判斷和迴圈的花括號不跨行。
2. 空格
- if和條件括號之間必須空格，花括號前必須空格；
- foreach和條件括號之間必須空格，花括號前必須空格；
- 函式內逗號隔開變數時，逗號後必須空格。
八、研發思想
1. 程式碼的優雅性：匠人精神
何為匠人精神？當你做一件事情就全身心的投入進去，做到你目前所能達到的極致，再通過你總結的經驗去雕琢它，理解它，超越它。codeing也是一樣，程式碼寫得好不好，用不用心，誰看誰知道。我們要的不是一個控制器寫上個八九百行程式碼完成實際業務即可的結果，而是除了你之外，其他同事都看得懂、看的舒服、使用方便的code。
注意縮排：合理的使用tab與空格縮排會使你的程式碼相對美觀很多，方便其他同事閱讀。
合理命名：方便與變數的命名儘可能簡短、易懂。比如在一個邏輯方法裡變數$newcurrencydata，字面意思易懂（新的貨幣資料），但變數名過長，會帶來閱讀與編寫的不便，但如果太短，如$datac，那卻是不清不楚的。
2. 高複用性：邏輯原子化
在編寫邏輯層的時候應多方面考慮複用性，易用性，原子化的問題。
如實際業務【使用者註冊】：可拆分為多個原子邏輯，如登錄檔單靜態效驗、檢查使用者是否存在、註冊成功、插入日誌、使用者登入等等，當其他業務需要對應的原子邏輯時，比如檢查使用者是否存在，那麼便可以直接例項化之前的logic直接呼叫了。
3. 高效能
laravel自帶有trace，開啟後可以看到當前所有執行的SQL與頁面的詳細開銷，特別是在有迴圈操作與多表操作處應仔細審查，編寫是否合理？是否可以優化？是否合理的使用快取處理？哪怕頁面載入減少了1s，那也是一種進步。你的細心與眼界直接決定了你的程式碼效能。
4. 低冗餘
不要重複造輪子、不要重複造輪子、不要重複造輪子....
重要的事情說三遍，當一段程式碼你重複寫了兩次以上時你就應該思考設計是否合理，而不是為了完成功能而cpoy過去改一改應付而已。
九、其他說明
1. 一個方法中，同一個函式只能執行一次；
2. 一個方法內，不能有太多if {…} else { … }，如果不是極其特殊的原因，不用if {} else {}，在做邏輯判斷時，最好可以進行單個if截斷，如下圖：
3. 每個業務邏輯方法的 “ 圈複雜度 ” 不能超過4；