PSR規範0 4整理

psr規範

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

psr-0 (autoloading standard) 自動載入標準 (2023年10月21起被官方棄用 由psr4替代)
psr-1 (basic coding standard) 基礎編碼標準 
psr-2 (coding style guide) 編碼風格嚮導 
psr-3 (logger inte***ce) 日誌介面 
psr-4 (improved autoloading) 自動載入的在用版本。
#注：另有psr6（快取介面規範）psr7（http訊息介面規範）psr11、psr13、psr15、psr16、psr17本文不做介紹

自動載入標準

乙個完全合格的namespace和class必須符合這樣的結構：「\< vendor name>(< namespace>)*< class name>」

每個namespace必須有乙個頂層的namespace（」vendor name」提供者名字）

每個namespace可以有多個子namespace

當從檔案系統中載入時，每個namespace的分隔符(/)要轉換成directory_separator(作業系統路徑分隔符)

在類名中，每個下劃線要轉換成directory_separator(作業系統路徑分隔符)。在namespace中，下劃線是沒有（特殊）意義的。

當從檔案系統中載入時，合格的namespace和class一定是以 .php 結尾的verdor name,namespaces,class名可以由大小寫字母組合而成（大小寫敏感的）

注：因為已經廢棄，這裡不再多做介紹

這裡先介紹psr4，好和上面的psr0作對比,因為他是公升級版的psr-0自動載入規範

psr4是關於由檔案路徑自動載入對應的類的相關規範，本規範是可互操作的。可以作為任一自動（包括psr-0）載入規範的補充，此外，psr4還包括自動載入的類對應的檔案存放路徑規範。

此處的「類」泛指所有的class類、介面、traits可復用**塊以及其他類似結構。

乙個完整的類名需要具有以下結構

《命名空間》(《子命名空間》)*《類名》

完整的類名必須要有乙個頂級命名空間，被稱為「vendor namespace」

完整的類名可以有乙個或多個子命名空間

完整的類名必須有乙個最終的類名

完整的類名中任意一部分中的下劃線都是沒有特殊意義的

完整的類名可以由任意大小寫字母組成

所有類名都必須是大小寫敏感的

當根據完整的類名載入相應的檔案

完整的類名中，去掉最前面的命名空間分隔符，前面連續的乙個或多個命名空間和子命名空間，作為「命名空間字首」，其必須至少對應乙個基礎目錄。

緊接命名空間字首後的子命名空間必須與相對應的「基礎目錄」的子目錄相匹配，其中的命名空間分隔符作為目錄分割符

末尾的類名必須與對應的.php為字尾的檔案同名

自動載入器（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則規定類名中的下劃線_會被轉化成目錄分隔符。

php原始檔必須只使用

**必須遵循psr-1中的編碼規範

**必須使用四個空格符而不是tab鍵進行縮排。

每行的字元數應該軟性保持在80個內，理論上不可多於120個，但一定不能硬性限制

每個namespace命名空間宣告語句和use語句塊後面，必須插入乙個空白行

類的開始花括號必須在類宣告後自成一行，結束花名號也必須在類主體後自成一行

函式的開始花括號必須在函式宣告後自成一行，結束花名號也必須在函式主體後自成一行

類的屬性和方法必須新增訪問修飾符（private protected以及public），abstract以及final必須宣告在訪問修飾符之前，而static必須宣告在訪問修飾符之後。

控制結構的關鍵字後必須要有乙個空格符，而呼叫方法或函式時則一定不能有。

控制結構的開始花括號必須寫在宣告的同一行，而結束花括號必須寫在主體後自成一行。

控制結構的開始左括號後和結束右括號前，都一定不能有空格符。

示例**

<?php
namespace
vendor\package;
usefoointe***ce;
usebarclass
asbar;
useothervendor\otherpackage\bazclass;
class
fooextends
barimplements
foointe***ce
elseif ($a > $b) else 
}final
public
static
function
bar()
}

通常還有以下幾點需要注意

對於php檔案：

關鍵字和 true/false/null

命名空間

<?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等。這一類的寫法規範也是經常容易出現問題的，也要規範一下。在關鍵字和後面的判斷條件中間應該加空格，在判斷條件和左大括號之間也要加空格。

本規範的主要目的，是為了讓類庫以簡單通用的方式接收乙個psr\log\loggerinte***ce物件，來記錄日誌資訊。框架以及cms內容管理系統如有需要，可以擴充套件介面以用於它們自己的

目的，但須遵循本規範，才能在使用第三方的類庫檔案時，保證日誌介面仍能正常對接。

loggerinte***ce 介面對外定義了八個方法，分別用來記錄rfc 5424中定義的八個級別：debug、info、notice、warning、error、critical、alert，emergency。

第九個方法-log，其第乙個引數為日誌的等級，可使用乙個預定義好的等級常量作為引數來呼叫此方法，必須與直接呼叫以上八個方法具有相同的效果。如果傳入的等級常量引數沒有預先定義，就必須丟擲psr\log\invalidargumentexception型別的異常，在不確定的情況下，使用者不該使用未支援的等級常量來呼叫此方法。如果有用過monolog就應該對這裡有較深的理解。

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

「「

PSR規範0 4整理

PSR編碼規範

PSR規範 php編碼規範

PSR 規範 PSR 3 日誌介面規範

PSR規範0 4整理

PSR編碼規範

PSR規範 php編碼規範

PSR 規範 PSR 3 日誌介面規範

相關推薦