漫談PHP代碼規範

天天學習一點點 編程PDF電子書、視頻教程免費下載：
http://www.shitanlife.com/code

 

前言

雖然說PHP是世界上最好的語言，可是寫出來的PHP代碼卻每每不是最美觀的。究其緣由，可能正式由於PHP簡單易上手，適合快速迭代的特性，致使了咱們沉浸在迅速完成需求迭代的竊喜中，卻忘記了規範性、忽略了易維護性，給後人挖了無數的坑，後面維護起來簡直想罵娘。各位PHPer不妨問一下本身是否曾經寫過下面的代碼？

【1】一個函數寫了兩百行甚至更多

【2】一個函數的參數有七八個甚至十幾個

【3】單行代碼/字符串最長超過了120個字符

【4】一個PHP文件寫了幾千行

【5】修改代碼的時候沒有把對應的註釋也修改一下

【6】不使用web框架提供的封裝，而是直接用$_POST, $_GET, $_SESSION這些全局變量

【7】……

其實以上問題，在咱們的項目中真的全都存在。寫出上面的代碼並不會影響代碼功能的正常運行，不過所謂前人栽樹後人乘涼，雜亂的代碼就像一堆雜草，後人維護一堆雜草遠比一顆大樹痛苦的多。這其中帶來的效率損失恐怕很難量化。試想一下閱讀一個500行的函數，其中的局部變量就定義了不下50個，你看到一個變量時，腦海中根本想不到這個變量表明的含義，又要回去找定義它的地方，一步步跟蹤下來或許思路早就被打斷了。若是閱讀一個50行的函數，整個函數體在一個電腦屏幕就能夠容納，連鼠標都不用翻動就能夠看到所有，這時內心會有多麼舒坦。

 

一些反面的例子

【1】無邊無際的函數參數

 

【2】寫了20000多行的代碼文件

 

【3】手拼SQL語句，「貌似」很便捷

 

【4】六層foreach嵌套

 

 

作出改變

曾經看到過不少開發組，意識到代碼規範問題以後，會去制定本身的代碼規範。曾經咱們也但願全部的開發坐下來，你們友好地協商出一份統一的代碼規範。然而，這麼作第一是很花時間，第二是不夠細緻，討論中很難涉及到編碼中的全部方面，第三也是最重要的一點，根本沒法達成一致……想必你們都據說過程序界的一個經久不衰的段子，就是編碼應該用空格縮進仍是用tab縮進。恰恰代碼規範這種東西，它是沒有標準答案的，你能夠列出10條使用空格作縮進的好處，但立刻就會有人提出10條使用tab作縮進的好處。「討論」這種方式根本行不通。

 

要想讓你們指定並遵循一個沒有標準答案的「標準」，光靠討論是出不來結果的，這個時候咱們須要的可能就是「權威」以及「強權」。「權威」是指去尋找業界大牛們究竟是怎麼作的，把他們的作法做爲咱們的「標準」總歸不會有錯。「強權」則是指肯定了「標準」之後，依靠開發leader去強推給組內全部人，沒有討論的餘地。「權威」保證了代碼規範的正確性，「強權」保證了代碼規範的執行力。

 

誰是「權威」？

有了上面的思路之後，咱們就要討論一下誰的代碼規範才能表明「權威」。平時使用PHP作Web開發，想必你們必定會用到各類PHP框架，例如Laravel，Symfony，Yii Framework，Zend Framework等等。做爲全球知名的開源框架，這些框架裏的代碼應該是很是符合規範的。那麼他們符合的是什麼變那麼規範呢？

 

其實隨便一搜索你就能夠找到了，絕大多數框架都遵循PSR（PHP Standard Recommendation）規範。PSR是由一個叫作PHP-FIG（Framework Interoperability Group）的組織經過民主投票的方式制定出來的規範。早在2009年的一次PHP技術會議上，各個PHP框架的做者自發成立了PHP-FIG組織，該組織的主要目的是但願給各個框架做者們提供一些優秀的設計規範並但願各個框架統一遵照。所以PSR其實表明了框架的設計規範，包括但不只僅是代碼書寫規範。

 

PSR規範目前有從PSR一、PSR二、……、PSR17（還在擴展中）等十幾項規範，涵蓋了PHP Web框架設計的方方面面。而咱們最關心的其實應該是PSR1和PSR2，這兩個所描述的正式PHP編碼的規範。有興趣的話你們能夠去他們的官方網站瞧一下（http://www.php-fig.org/），包括目前都有哪些規範、哪些正在制定中、組織的介紹等等。

 

目前絕大多數PHP Web框架都遵循PSR2的代碼規範。

 

除了PSR，還有什麼PHP代碼規範？

當我看到PSR規範的影響力時，基本已經肯定使用它做爲咱們項目中的編碼規範。不過本着科學的態度，咱們仍是要了解一下業界還有哪些其它的規範。

 

若是你是一個PHP的老手，可能之前常常會用PEAR管理PHP庫（雖然目前PEAR已經徹底被Composer蓋住了風頭）。PEAR也有一套本身的代碼規範（連接：https://pear.php.net/manual/en/standards.php），PEAR規範應該屬於PHP最先期的規範了，不少其餘代碼規範都從它演化而來。它的要求也是最爲寬鬆的。

 

若是你據說過PHP代碼檢查與美化工具PHP Code Sniffer（https://github.com/squizlabs/PHP_CodeSniffer），那必定能夠看到其中提供的MySource、Squiz、PHPCS規範。PHP Code Sniffer是一個叫Squiz的公司開源出來的工具，因此確定要推薦一把本身公司使用的代碼規範，即Squiz規範，該規範比PSR要嚴格不少。舉個例子，下面的寫法在PSR2中沒有不符合規範，可是在Squiz中是不合規範的。Squiz規定，一個類內部須要引用自身的時候，不得使用類名，而是使用self。

1 2 3 4 5 6 7 8 9 10 11 12 13

class  Test   {        public  function  getInstance()        {            return  new  Test();  // 符合PSR，但不符合Squiz規範，Squiz規範要求這裏寫爲 new self();        }   }

　　

PHPCS則是PHP Code Sniffer工具自身的代碼使用的規範，比Squiz稍寬鬆一些，可是依然比PSR嚴格不少。而MySource規範則是最嚴格的一個，用於該公司的MySource Mini項目，其中不只有PHP規範，甚至還有JS和CSS的規範。一個工具居然提供了三個本身公司的規範……

 

簡單總結一下：

嚴格程度 PEAR < PSR < PHPCS < Squiz < MySource

流行程度 PSR > PEAR > 其餘

 

實際上，除此以外還有一些PHP框架也提供了屬於本身框架的規範，例如CodeIgniter（http://codeigniter.org.cn/user_guide/general/styleguide.html）。比較奇怪這個框架爲何沒有加入PHP-FIG，不過這類框架本身定義規範通常都比較小衆。若是你使用了CodeIgniter，那固然是建議遵循框架自身的規範。這裏就再也不詳細研究了。

 

根據PHP Code Sniffer做者的推薦，若是你還不知道用哪一個好，那就先嚐試用PSR2吧！

 

如何行動？

其實在規範執行的過程當中，咱們最開始必定會碰到不少困難。好比本身原本的代碼書寫習慣和規範不同，剛一調整的時候會有些彆扭；動輒數十頁的規範內容，根本記不住，怎麼辦？PSR2的代碼規範連接以下：http://www.php-fig.org/psr/psr-2/，看上去滾動條很短，頁面內容太多，實際上它們徹底能夠壓縮在一張紙上。在組內項目開發中，把PSR2用中文稍加翻譯（表達一樣意思，中文語句比英文短不少），縮小一些字號，放在一張紙上打印出來，貼在辦公桌上，時間久了天然能夠養成一個好的習慣。此方法在項目組內實行一段時間後，效果喜人。

 

結語

寫了一大長篇PHP代碼規範，卻沒有出現任何規範的詳細內容。主要由於通常在博客裏面寫的長篇大論的規範貌似你們都不喜歡看~做爲「漫談」，只是記錄一下本身尋找一份「科學」的代碼規範的過程。規範的內容有些可能與你平時的習慣不太一致，不過這就是各個PHP Web框架開發者一致的選擇。

 

天天學習一點點 編程PDF電子書、視頻教程免費下載：http://www.shitanlife.com/code