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訊息介面規範）psr11、psr13、psr15、psr16、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)聲明代碼塊後面必須有一行空行。

例如：

<?phpnamespace 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到了想要的知識。