看完這篇，你的PHP代碼優雅一個檔次。

引言

今天老王同窗跟我說，他的代碼好糟糕，像一坨xiang。問我要怎麼

提升本身的代碼質量，讓本身代碼看得順眼一點，舒服一點， 就像

看到大長腿MM，兩眼放光那種。

因而我: 你先這樣，而後這樣，而後再那樣。。。。。。<!--more-->

老王同窗: 別鬧, 究竟是哪樣?

好的, 我要開始裝13了。。。

基本規範

先說一下最基本的東西:

• 變量名使用駝峯命名。不懂的單詞不要用拼音，而是要查詞典找到對應的單詞。
• 常量命名使用大寫下劃線方式命名。如:SYSTEM_EROOR = 50000。
• 縮進使用Tab鍵，不要打一堆空格作縮進。
• 類名首字母大寫駝峯命名，須要見名知其意，註釋說明這個類的功能。例如:

• 方法名駝峯命名，方法行數儘可能控制在80行左右，註釋說明函數幹嗎用的。

• 花括號獨佔一行，例如:

• foreach慎用引用，例如如下代碼會有問題:

預期結果是輸出: 2 4 6，實際結果是2 4 4, 至於爲何可
以看我以前的文章: PHP中&符號你真的瞭解嗎?`。
能夠使用array_walk方法避免這個問題, 示例:

• 避免if, elese嵌套過深，不少嵌套能夠經過提早終止來消除, 舉個簡單的例子:

建議使用第二種方式，不符合條件的直接返回，剩下的就是符號條件的，那麼避免了在if裏面寫不少代碼。

• 多個if/else使用switch來替代，PHP8.0版本能夠使用match更爲簡潔。
• phpstorm中安裝SonarLint插件。若是你寫的代碼出現虛線，說明不太理想，那麼能夠根據提示修改，相信有強迫症的同窗必定會改，長此以往代碼就很規範了。例如:
  
  方法未使用，方法名不規範已經告訴你了，能夠快捷修改，也能夠本身修改。

框架規範

• 前面說得都是比較基礎的東西，接下來纔是主要的內容。
• 相信不少同窗都用過經常使用的thinkphp丶laravel丶yii等流行框架之一。
• 這些框架都是MVC架構的，看過不少人的代碼，要麼把業務邏輯寫在控制器裏面，要麼寫在Model裏面， 寫在Model裏面相比寫控制器裏面的還相對好一點。其實對於大型項目都不太友好。
• 下文以Laravel框架爲例。

參數驗證

• API須要進行參數驗證，可是參數驗證寫在哪裏比較優雅呢？可能不少人在controller定義規則，而後在調用驗證方法，那麼驗證那段代碼將在每一個API裏面出現，例如我同事寫的。

  這段代碼在每一個API裏面均會出現一次，豈不是很囉嗦，那麼如何解決呢？

• 在Laravel的http目錄下創建一個Requsts目錄，用於存放請求的參數驗證類。創建一個BaseRequest類：

好比登陸須要參數驗證再創建一個LoginRequest類繼承這個BaseRequest。

• 使用的時候只要在Controller的方法中注入這個請求類便可。

這裏獲取請求參數的時候會對錶單進行驗證，不然參數驗證失敗會調用剛剛Request積累定義的方法拋Json異常，返回信息給客戶端。

控制器

控制器的主要工做負載獲取請求數據和返回內容，不該作更多的事情，那麼能夠定義一個Service層來處理業務邏輯。
因此個人控制器的代碼只有一行。

• 在Laravel的app目錄下創建一個Services文件夾用於存放Service類，創建一個BaseService類:

而後創建一個UserService來處理用戶相關的業務邏輯。

在UserController中注入這個UserService使用:

Model

Model不建議寫業務邏輯。Model主要是用來定義一些內容，不該該操縱數據。

Model的數據操縱應該放在Repository中，在Laravel的app目錄下創建一個文件夾Repositories。

定義BaseRepository:

定義UserRepository，用於用戶數據相關的操做, 在構造方法中注入UserModel:

常量

項目中不少常量該怎麼定義？

在app目錄建立一個Constant目錄， 再創建一個Contstant類來保存這些自定義常量。

這樣的好處是:

• 自定義常量能夠集中的管理。
• 修改常量值的時候，只須要在這個類中找修改一次便可，代碼更新維護性好。

附錄