PSR規範0-4整理

PSR規範

psr規範

---

引言： PSR 是 PHP Standard Recommendations 的簡寫，由 PHP FIG 組織制定的 PHP 規範，是 PHP 開發的實踐標準。這些規範的目的是：經過框架做者或者框架的表明之間討論，以最低程度的限制，制定一個協做標準，各個框架遵循統一的編碼規範，避免各家自行發展的風格阻礙了 PHP 的發展，解決這個程序設計師由來已久的困擾。截止到筆者文章psr在用的共11套規範，下面介紹了其中四個和已經棄用的psr0規範。

PSR-0 (Autoloading Standard) 自動加載標準 (2014年10月21起被官方棄用 由psr4替代)
PSR-1 (Basic Coding Standard) 基礎編碼標準 
PSR-2 (Coding Style Guide) 編碼風格嚮導 
PSR-3 (Logger Interface) 日誌接口 
PSR-4 (Improved Autoloading) 自動加載的在用版本。
#注：另有psr6（緩存接口規範）psr7（HTTP消息接口規範）psr十一、psr1三、psr1五、psr1六、psr17本文不作介紹

附上官網地址psr

psr0（官方已廢棄）

自動加載標準

1. 一個徹底合格的namespace和class必須符合這樣的結構：「< Vendor Name>(< Namespace>)*< Class Name>」
2. 每一個namespace必須有一個頂層的namespace（"Vendor Name"提供者名字）
3. 每一個namespace能夠有多個子namespace
4. 當從文件系統中加載時，每一個namespace的分隔符(/)要轉換成DIRECTORY_SEPARATOR(操做系統路徑分隔符)
5. 在類名中，每一個下劃線要轉換成DIRECTORY_SEPARATOR(操做系統路徑分隔符)。在namespace中，下劃線是沒有（特殊）意義的。
6. 當從文件系統中載入時，合格的namespace和class必定是以 .php 結尾的verdor name,namespaces,class名能夠由大小寫字母組合而成（大小寫敏感的）

注：由於已經廢棄，這裏再也不多作介紹

psr4

這裏先介紹psr4，好和上面的psr0做對比,由於他是升級版的PSR-0自動加載規範
PSR4是關於由文件路徑自動載入對應的類的相關規範，本規範是可互操做的。能夠做爲任一自動（包括PSR-0）載入規範的補充，此外，PSR4還包括自動載入的類對應的文件存放路徑規範。

此處的「類」泛指全部的class類、接口、traits可複用代碼塊以及其餘相似結構。
一個完整的類名須要具備如下結構
<命名空間> ( <子命名空間> )* <類名>

1. 完整的類名必需要有一個頂級命名空間，被稱爲「Vendor namespace」
2. 完整的類名能夠有一個或多個子命名空間
3. 完整的類名必須有一個最終的類名
4. 完整的類名中任意一部分中的下劃線都是沒有特殊意義的
5. 完整的類名能夠由任意大小寫字母組成
6. 全部類名都必須是大小寫敏感的

當根據完整的類名載入相應的文件

1. 完整的類名中，去掉最前面的命名空間分隔符，前面連續的一個或多個命名空間和子命名空間，做爲「命名空間前綴」，其必須至少對應一個基礎目錄。
2. 緊接命名空間前綴後的子命名空間必須與相對應的「基礎目錄」的子目錄相匹配，其中的命名空間分隔符做爲目錄分割符
3. 末尾的類名必須與對應的.php爲後綴的文件同名
4. 自動加載器（autoloader）的實現必定不能拋出異常，必定不能觸發任一級別的錯誤信息以及不該該有返回值。

例如：

#完整的類名爲
\a\b\c\Log
#命名空間前綴前綴爲：
a\b
#前綴對應的基礎目錄爲：
./vendor
#文件實際目錄爲：
./vendor/c/Log.php
#注：即把去掉最前面的命名空間分隔符後的a\b\c\Log中的命名空間前綴替換成基礎目錄，而後把命名空間分隔符替換成目錄分隔符，並把文件名補上後綴 .php 。

PSR-4和PSR-0最大的區別是對下劃線（underscore)的定義不一樣。PSR-4中，在類名中使用下劃線沒有任何特殊含義。而PSR-0則規定類名中的下劃線_會被轉化成目錄分隔符。

psr1 基本代碼規範

1. PHP源文件必須只使用 <?php 和 <?= 這兩種標籤。（php標記有多種方式）
2. 源文件中php代碼的編碼格式必須是不帶字節順序標記(BOM)的UTF-8。（注：PHP在設計時就沒有考慮BOM的問題，也就是說他不會忽略UTF-8編碼的文件開頭BOM的那三個字節致使出現奇怪的錯誤。）

3. 一個源文件建議只用來作聲明（類(class)，函數(function)，常量(constant)等）或者只用來作一些引發從屬效應的操做（例如：輸出信息，包含文件，修改.ini配置等），但不能同時使用二者。
   注：「從屬效應」(side effects)一詞的意思是，僅僅經過包含文件，不直接聲明類、函數和常量等，而執行的邏輯操做。 「從屬效應」包含卻不只限於：生成輸出、直接的 require 或 include、鏈接外部服務、修改 ini 配置、拋出錯誤或異常、修改全局或靜態變量、讀或寫文件等。 這個不少人都不遵照，可是基本上全部框架裏都不會把修改.ini配置和聲明類或函數放到一塊兒，好比框架index.php入口文件只定義宏常量和修改.ini等

4. 命名空間(namespace)和類(class) 必須遵照PSR0或psr4標準。
5. 類名(class name) 必須使用駱駝式(StudlyCaps)寫法(注：StudlyCaps即首字母大寫駝峯式)。
6. 類(class)中的常量必須只由大寫字母和下劃線組成。

7. 方法名(method name) 必須使用駝峯式(cameCase)寫法。

psr2 代碼風格

1. 代碼必須遵循PSR-1中的編碼規範
2. 代碼必須使用四個空格符而不是tab鍵進行縮進。
3. 每行的字符數應該軟性保持在80個內，理論上不可多於120個，但必定不能硬性限制
4. 每一個namespace命名空間聲明語句和use語句塊後面，必須插入一個空白行
5. 類的開始花括號必須在類聲明後自成一行，結束花名號也必須在類主體後自成一行
6. 函數的開始花括號必須在函數聲明後自成一行，結束花名號也必須在函數主體後自成一行
7. 類的屬性和方法必須添加訪問修飾符（private protected以及public），abstract以及final必須聲明在訪問修飾符以前，而static必須聲明在訪問修飾符以後。
8. 控制結構的關鍵字後必需要有一個空格符，而調用方法或函數時則必定不能有。
9. 控制結構的開始花括號必須寫在聲明的同一行，而結束花括號必須寫在主體後自成一行。
10. 控制結構的開始左括號後和結束右括號前，都必定不能有空格符。
    示例代碼

<?php
    namespace Vendor\Package;
    
    use FooInterface;
    use BarClass as Bar;
    use OtherVendor\OtherPackage\BazClass;
    
    class Foo extends Bar implements FooInterface
    {
        public function sampleMethod($a, $b = null)
        {
            if ($a === $b) {
                bar();
            } elseif ($a > $b) {
                $foo->bar($arg1);
            } else {
                BazClass::bar($arg2, $arg3);
            }
        }
    
        final public static function bar()
        {
            // method body
        }
    }

一般還有如下幾點須要注意

對於php文件：

• 全部的php文件都必須以Unix LF（換行）做爲結束符
• 全部的php文件都必須以一個單獨的空行結尾
• 純PHP代碼源文件的關閉標籤?>必須省略。

關鍵字和 True/False/Null

• php的關鍵字，必須小寫
• php產量 true ，false，null也必須小寫

命名空間

• 命名空間(namespace)的聲明後面必須有一行空行。
• 全部的導入(use)聲明必須放在命名空間(namespace)聲明的下面。
• 一句聲明中，必須只有一個導入(use)關鍵字。
• 在導入(use)聲明代碼塊後面必須有一行空行。

例如：

<?php
namespace Vendor\Package;

use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

// ... additional PHP code ...

控制結構

if ，else ，elseif ，while ，do while ，switch case ，for， foreach，try catch等。這一類的寫法規範也是常常容易出現問題的，也要規範一下。在關鍵字和後面的判斷條件中間應該加空格，在判斷條件和左大括號之間也要加空格。

psr3日誌接口規範

本規範的主要目的，是爲了讓類庫以簡單通用的方式接收一個Psr\Log\LoggerInterface對象，來記錄日誌信息。框架以及CMS內容管理系統若有須要，能夠擴展接口以用於它們本身的
目的，但須遵循本規範，才能在使用第三方的類庫文件時，保證日誌接口仍能正常對接。

LoggerInterface 接口對外定義了八個方法，分別用來記錄RFC 5424中定義的八個級別：debug、info、notice、warning、error、critical、alert，emergency。

第九個方法-log，其第一個參數爲日誌的等級，可以使用一個預約義好的等級常量做爲參數來調用此方法，必須與直接調用以上八個方法具備相同的效果。若是傳入的等級常量參數沒有預先定義，就必須拋出Psr\Log\InvalidArgumentException類型的異常，在不肯定的狀況下，使用者不應使用未支持的等級常量來調用此方法。若是有用過monolog就應該對這裏有較深的理解。

例如，日誌等級能夠定義以下：

<?php
    
    namespace Psr\Log;
    
    /**
     * Describes log levels
     */
    class LogLevel
    {
        const EMERGENCY = 'emergency';
        const ALERT     = 'alert';
        const CRITICAL  = 'critical';
        const ERROR     = 'error';
        const WARNING   = 'warning';
        const NOTICE    = 'notice';
        const INFO      = 'info';
        const DEBUG     = 'debug';
    }

日誌這裏想必你們接觸的也很少，若是想了解能夠看一看monolog的源碼。 本文到此就結束，但願你們get到了想要的知識。