PHP-PSR 現代PHPer的開發規範

原文是在我本身博客中，小夥伴也能夠點閱讀原文進行跳轉查看，還有好聽的背景音樂噢~

    PSR是PHP Standards Recommendation的簡稱，意爲PHP推薦標準。要想了解PSR，首先得知道制定這一標準的人/組織是誰————PHP-FIG。

PHP-FIG

PHP-FIG全稱爲PHP Framework Interop Group,是一個組織，這個組織的成員由一些PHP框架的表明組成，這些人聚在一塊兒「討論框架之間的共性，尋找能夠合做的方式」。PHP-FIG制訂了推薦規範，PHP框架能夠自願實現這些規範，改進其餘框架的通訊和共享功能。

PHP-FIG的使命是實現框架之間的互操做性。

PSR-1：基本的代碼風格

    在文章的最開始，咱們就已經簡單介紹過什麼是PSR，PSR是PHP標準，而PSR-1是PHP最基本也是最簡單的標準。

PHP標籤

必須把代碼放在<?php ?>或<? ?>標籤中。不得使用其它的標籤句法

這點相信不少PHPer都很容易遵照，並且在現實擼代碼中通常都是採用正常的<?php ?>標籤

編碼

全部PHP文件都必須使用UTF-8字符集編碼，並且不能有字節順序標記（Byte Order Mark,BOM）

這個也很常見，就是無BOM和有BOM格式，記得剛開始敲PHP代碼的時候，前輩老是很關照，必定要用IDE調成無BOM格式啊，當時表示懵懂，而後就跟着作了，如今看到這裏，又從新查了資料，找到了爲何不能使用有BOM格式的緣由，BOM會產生多餘的輸出，就像無緣無故多了一個空行：

php在處理BOM頭的時候，有時候存在錯誤，可能形成你在使用 header 或 session_start 之類的函數時，出現 文件已經輸出的錯誤，多數都是由於BOM頭送出去了。。由於在php看來，成了一個空格。因此使用無BOM的格式

目的

一個PHP文件能夠定義符號（類、性狀、函數、常量等），或者執行有反作用的操做（生成結果或者處理數據），但不能同時作兩件事

這個規定的意思差很少就是一個變量、方法或者一個類，只能相應完成一個操做、作一件事情，這樣保證了代碼的清晰易懂，也保證了方法、變量的單一性，各司其職。其實也是爲了方便，咱們在之後項目/應用較大時，能夠很好的解耦

自動加載

PHP的命名空間和類必須遵照PSR-4自動加載器標準

後續看PSR-4的具體解釋

類的名稱

PHP類的名稱必須使用駝峯式，又名標題式

駝峯式和分詞式（每一個單詞用_隔開）這兩種寫法，記得之前存在很大的爭議，有人支持駝峯(GirlFriend),有人支持分詞式（girl_friend），如今好了，統一規定出來了，爲了PHP更好的發展，那就委屈支持分詞式的兄弟，統一駝峯了。記得公司的CI2項目，用的就是這種分詞式，不過也是框架規定，後來在本身的項目中，本身有預感的使用了駝峯式，哈哈，爲本身的眼光點贊~

常量的名稱

PHP的常量名稱必須大寫；

這點應該是毋庸置疑的吧，最開始寫PHP的時候，這個寫法已經根深蒂固了。

方法的名稱

使用駝峯式(boyFriend)

方法的命名和類的命名方式有些類似，不過仍是有些區別：類的命名規定首字母大寫（BoyFriendMoney）,而方法的命名規定首字母小寫（boyFriendMoney）

PSR-2：嚴格的代碼風格

PSR-2 相較於PSR-1是更爲嚴格的代碼規範。我的和官方都認爲開發者應該遵循更爲嚴格的代碼標準，在現代的PHP生態系統中，風格統一，能夠更好的讓其餘開發者理解PHP代碼。

貫徹PSR-1

使用PSR-2 以前先要貫徹PSR-1

縮進

使用四個空格縮進。

關於縮進這個問題，相信有不少爭議。我在真正正視這個問題以前，一直使用的都是IDE的tab鍵。而後當同事和本身在編寫同一文件的時候，就會出先代碼縮進不一的狀況，致使代碼結構很是亂。因此在出現這個問題以後，就統一了一下文件縮進的標準，以四個空格爲縮進。這樣的話，就算是用不一致的編輯器打開，效果也是同樣的。
不少IDE均可以設置tab鍵，百度一下就能夠搜到。

文件和代碼行

PHP文件必須使用UNIX風格的換行符（LF），最後要有一個空行，並且不能使用PHP關閉 ?> 標籤。

最開始我也不懂爲何在純PHP頁面中不使用關閉 ?> 標籤，後來在書中找到了答案

爲了不意料以外的輸出錯誤，若是加上關閉標籤，並且在關閉標籤後有空行，那麼這個空行也被當成輸出，致使錯誤（例如，設定http首部時）

關鍵字

關鍵字，要使用小寫；

以前不知道在哪兒看的PHP的教程，上面寫的PHP代碼像true、false這樣的關鍵字都使用的是大寫TRUE、FALSE，我也一直在這樣使用，後來看到PSR-2的規範，才知道應該要使用小寫，心累~

命名空間

每一個命名空間語句後必須跟着一個空行。相似的，使用use關鍵字導入命名空間或爲命名空間建立別名時，在一系列use聲明語句後要加一個空行

相似於：

<?php
// 聲明本文件的命名空間
namespace My\Friend;

// 導入命名空間
use Other\Friend;

class GirlFrined
{
    
}

類

類定義體的起始括號應在類名以後另起一行寫；
類定義體的結束括號必須在定義體以後新起一行寫；

例：

<?php

class Frined
{
    public function getSex()
    {
        // do something
    }
}

方法

方法定義體的起始括號應在方法名以後另起一行寫；
方法定義體的結束括號必須在方法定義體以後新起一行寫；

請參考上面類示例中方法的例子。

可見性

一、類中的每一個屬性和方法都要聲明可見性。可見性由public、protected或者private指定，其做用是決定在類的內部和外部如何訪問屬性的方法。
二、私有方法的名稱前加上下劃線
三、若是類屬性聲明爲abstract和final，這兩個限定符必須放在可見性關鍵字以前
四、若是屬性、方法聲明爲static，這個限定符必須放在可見性關鍵字以後

例子：

// 一、2
public $sex;
private $_sex;
protected $sex;

// 三、
abstract public $sex;
final public $sex;

// 四、
public static $sex;
public static $age;

控制結構

全部控制結構關鍵字後面都要有一個空格。控制結構關鍵字包括：if、elseif、else、switch、case、while、do while、for、foreach、try、catch。若是控制結構關鍵字後面有一對圓括號，起始圓括號後面不能有空格，結束圓括號以前不能有空格。與類和方法的定義體不一樣，控制結構關鍵字後面的起始括號應該和控制機構關鍵字寫在同一行。控制結構關鍵字後面的結束括號必須寫在單獨一行。

例：

/** 
* 錯誤的示例：
* 這裏有4個錯誤：
* 一、if關鍵詞後面和圓括號以前沒有空格
* 二、圓括號先後有空格
* 三、後圓括號和起始括號以前沒有空格
* 四、else關鍵詞先後沒有空格
**/
if( 1 == true ){
    // do something
}else{
    // do something
}

/** 
* 正確的示例：
**/
if (1 == true) {
    // do something
} else {
    // do something
}

PSR-3：日誌記錄器接口

日誌記錄器

PHP-FIG發佈的第三個推薦規範和前兩個不一樣，這個有點特殊，是一個接口。規定PHP日誌記錄器組件能夠實現的方法。

日誌記錄器是對象，用於把不一樣重要程度的消息寫入指定的輸出。記錄的消息用於診斷、檢查和排除應用中的操做、穩定性和性能方面的問題。例如：開發的時候把調試信息寫入到文本文件，把網站的流量統計信息記錄到數據庫等。

相信基本上全部的框架中都實現了日誌功能，那麼若是想要使用PSR-3規範的日誌記錄器，該怎麼作呢？首先要知足兩點：

1. 日誌功能委託給第三方庫實現
2. 最終用戶能選擇他們喜歡的日誌記錄器組件

編寫PSR-3日誌記錄器

符合PSR-3推薦規範的PHP日誌記錄器組件，必須包含一個實現Psr\Log\LoggerInterface接口的PHP類。PSR-3接口複用了RFC 5424系統日誌協議，規定要實現9個方法：

下面的代碼是我從PHP-FIG的官網上拿過來的，想了解詳細信息的能夠 點我

<?php

namespace Psr\Log;

interface LoggerInterface
{
    
    public function emergency($message, array $context = array());
    public function alert($message, array $context = array());    
    public function critical($message, array $context = array());
    public function error($message, array $context = array());
    public function warning($message, array $context = array());
    public function notice($message, array $context = array());
    public function info($message, array $context = array());
    public function debug($message, array $context = array());
    public function log($level, $message, array $context = array());
}

這個類中的每個方法都對應RFC 5424協議的一個日誌級別，並且都接受兩個參數。第一個參數必須是一個字符串，或者有一個__toString()方法的對象。第二個參數爲數組，可選參數；

若是要編寫符合PSR-3規範的日誌記錄器，那麼就要建立一個實現Psr\Log\LoggerInterface接口的PHP類，並且要提供這個接口中每一個方法的具體實現

使用PSR-3日誌記錄器

PSR-3規範出來以後，達到這種效果的組件太多了，這裏就不介紹，如何實現這個接口的類了。如今有成熟的日誌記錄器組件，推薦monolog/monolog。這個組件徹底上線了PSR-3的接口，並且可使用自定義的消息格式化程序和處理程序擴展功能。
若是monolog知足不了平常的使用，咱們能夠在此基礎上拓展本身的方法，也很是簡單；

使用monolog示例：

<?php
use Monolog\Logger;
use Monolog\Handler\StreamHandler;

// 準備日誌記錄器
$logger = new Logger('my_logger');
$logger->pushHandler(new StreamHandler('logs/development.log', Logger::DEBUG));
$logger->pushHandler(new StreamHandler('logs/production.log', Logger::WARNING));
// 使用日誌記錄器
$logger->debug('This is debug message');
$logger->debug('This is warning message');

PSR-4：自動加載器

PHP-FIG發佈的第四個推薦規範描述了一個標準的自動加載器策略；自動加載器的意思就是指在程序運行時按需查找PHP類、接口（interface）或性狀（trait）並將其載入加載器。

自動加載器策略

PSR-4推薦規範不要求改變代碼的實現方式，只建議如何使用文件系統目錄結構和PHP命名空間組織代碼。PSR-4依賴PHP命名空間和文件系統目錄結構查找並加載PHP類、性狀和接口

爲何自動加載器很重要

舉一個很常見的場景，咱們引入文件一般都是採用require、include這樣的方法，這樣的方式簡單也可靠，可是若是咱們引入一兩個還好說，可是當咱們一個項目運行時須要引入幾十個文件呢，那咱們豈不是要寫幾十個require或者include？這樣既不方便，又不美觀，因此PHP-FIG在此基礎上考慮，規範了一個統一的自動加載器策略；

如何使用自動加載器

建議使用依賴管理器Composer自動生成的PSR-4自動加載器。
現代的PHP框架，laravel、Yii、TP5等都使用了依賴Composer的自動加載器策略，方便咱們下載組件和引入合適的類。

PSR-ME：制定本身的PHP規範

1. 遵循PSR-一、PSR-2的使用規範
2. 合適、精簡的變量、方法、類命名。能讓人看一眼就清楚是作什麼的
3. 儘可能編寫出高內聚、低耦合的代碼
4. 保持代碼結構整潔、美觀

總結

以上內容均來自《Mordern PHP》，中文名爲現代PHP，書中詳細的介紹了在現代化PHP開發中的新特性和良好實踐，很是好的一本書。PHP-FIG推出的PHP規範，並不必定說全部的PHP開發者必須遵照。制定這一規範的目的就是爲了，在全世界的PHP開發者在查看代碼的時候，能更加簡單和輕鬆。造出來的組件/輪子能夠很容易的就被全部開發者熟知和使用，同時也減小了咱們的工做投入率，使產出大於投入，效率更高更快。