phppsr規范
① psr 什麼意思
簡單來說psr就是規范了php開發的編碼風格,進行統一規范!
PSR 是 PHP Standard Recommendations 的簡寫，由PHP FIG組織制定的 PHP 規范，是 PHP 開發的實踐標准。
PHP FIG,FIG 是 Framework Interoperability Group（框架可互用性小組）的縮寫，由幾位開源框架的開發者成立於 2009 年，從那開始也選取了很多其他成員進來（包括但不限於Laravel, Joomla, Drupal, Composer, Phalcon, Slim, Symfony, Zend Framework等），雖然不是「官方」組織，但也代表了大部分的 PHP 社區。
項目的目的在於：通過框架作者或者框架的代表之間討論，以最低程度的限制，制定一個協作標准，各個框架遵循統一的編碼規范，避免各家自行發展的風格阻礙了 PHP 的發展，解決這個程序設計師由來已久的困擾。
目前已表決通過了 6 套標准，已經得到大部分 PHP 框架的支持和認可。
② 什麼是psr-0，psr-1，psr-2標准
轉自：http://www.nginx.cn/2677.html
FIG組織在制定跟PHP相關規范，簡稱PSR，PSR旨在通過討論我們代碼項目的共同點以找出一個協作編程的方法。
什麼是psr0強調自動載入的方式
下文描述了若要使用一個通用的自動載入器(autoloader)，你所需要遵守的規范：
規范
一個完全標準的命名空間(namespace)和類(class)的結構是這樣的：\*
每個命名空間(namespace)都必須有一個頂級的空間名(namespace)("組織名(Vendor Name)")。
每個命名空間(namespace)中可以根據需要使用任意數量的子命名空間(sub-namespace)。
從文件系統中載入源文件時，空間名(namespace)中的分隔符將被轉換為 DIRECTORY_SEPARATOR。
類名(class name)中的每個下劃線_都將被轉換為一個DIRECTORY_SEPARATOR。下劃線_在空間名(namespace)中沒有什麼特殊的意義。
完全標準的命名空間(namespace)和類(class)從文件系統載入源文件時將會加上.php後綴。
組織名(vendor name)，空間名(namespace)，類名(class name)都由大小寫字母組合而成。
示例
\Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php
\Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
\Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php
空間名(namespace)和類名(class name)中的下劃線
\namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/Class/Name.php
\namespace\package_name\Class_Name => /path/to/project/lib/vendor/namespace/package_name/Class/Name.php
以上是我們為實現通用的自動載入而制定的最低標准。你可以利用能夠自動載入PHP 5.3類的SplClassLoader來測試你的代碼是否符合這些標准。
實例
下面是一個怎樣利用上述標准來實現自動載入的示例函數。
<?php
function autoload($className)
{
$className = ltrim($className, '\\');
$fileName = '';
$namespace = '';
if ($lastNsPos = strrpos($className, '\\')) {
$namespace = substr($className, 0, $lastNsPos);
$className = substr($className, $lastNsPos + 1);
$fileName = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR;
}
$fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';
require $fileName;
}
SplClassLoader實現
下面的gist是一個按照上面建議的標准來自動載入類的SplClassLoader實例。這是依據這些標准來載入PHP 5.3類的推薦方案。
什麼是psr1，定義基本代碼規范
本節我們將會討論一些基本的代碼規范問題，以此作為將來討論更高級別的代碼分享和技術互用的基礎。
RFC 2119中的必須(MUST)，不可(MUST NOT)，建議(SHOULD)，不建議(SHOULD NOT)，可以/可能(MAY)等關鍵詞將在本節用來做一些解釋性的描述。
1. 概述
源文件必須只使用 和 這兩種標簽。
源文件中php代碼的編碼格式必須只使用不帶位元組順序標記(BOM)的UTF-8。
一個源文件建議只用來做聲明（類(class)，函數(function)，常量(constant)等）或者只用來做一些引起副作用的操作（例如：輸出信息，修改.ini配置等）,但不建議同時做這兩件事。
命名空間(namespace)和類(class) 必須遵守PSR-0標准。
類名(class name) 必須使用駱駝式(StudlyCaps)寫法 (譯者註：駝峰式(cameCase)的一種變種，後文將直接用StudlyCaps表示)。
類(class)中的常量必須只由大寫字母和下劃線(_)組成。
方法名(method name) 必須使用駝峰式(cameCase)寫法(譯者註：後文將直接用camelCase表示)。
2. 文件
2.1. PHP標簽
PHP代碼必須只使用長標簽()或者短輸出式標簽(<?= ?>)；而不可使用其他標簽。
2.2. 字元編碼
PHP代碼的編碼格式必須只使用不帶位元組順序標記(BOM)的UTF-8。
2.3. 副作用
一個源文件建議只用來做聲明（類(class)，函數(function)，常量(constant)等）或者只用來做一些引起副作用的操作（例如：輸出信息，修改.ini配置等）,但不建議同時做這兩件事。
短語副作用(side effects)的意思是 在包含文件時 所執行的邏輯與所聲明的類(class)，函數(function)，常量(constant)等沒有直接的關系。
副作用(side effects)包含但不局限於：產生輸出，顯式地使用require或include，連接外部服務，修改ini配置，觸發錯誤或異常，修改全局或者靜態變數，讀取或修改文件等等
下面是一個既包含聲明又有副作用的示例文件；即應避免的例子：
<?php
// 副作用：修改了ini配置
ini_set('error_reporting', E_ALL);
// 副作用：載入了文件
include "file.php";
// 副作用：產生了輸出
echo "<html>\n";
// 聲明
function foo()
{
// 函數體
}
下面是一個僅包含聲明的示例文件；即應提倡的例子：
<?php
// 聲明
function foo()
{
// 函數體
}
// 條件式聲明不算做是副作用
if (! function_exists('bar')) {
function bar()
{
// 函數體
}
}
3. 空間名(namespace)和類名(class name)
命名空間(namespace)和類(class)必須遵守 PSR-0.
這意味著一個源文件中只能有一個類(class)，並且每個類(class)至少要有一級空間名（namespace）：即一個頂級的組織名(vendor name)。
類名(class name) 必須使用StudlyCaps寫法。
PHP5.3之後的代碼必須使用正式的命名空間(namespace) 例子：
<?php
// PHP 5.3 及之後:
namespace Vendor\Model;
class Foo
{
}
PHP5.2.x之前的代碼建議用偽命名空間Vendor_作為類名(class name)的前綴
<?php
// PHP 5.2.x 及之前:
class Vendor_Model_Foo
{
}
4. 類的常量、屬性和方法
術語類(class)指所有的類(class)，介面(interface)和特性(trait)
4.1. 常量
類常量必須只由大寫字母和下劃線(_)組成。 例子：
<?php
namespace Vendor\Model;
class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
}
4.2. 屬性
本指南中故意不對$StulyCaps，$camelCase或者$unser_score中的某一種風格作特別推薦，完全由讀者依據個人喜好決定屬性名的命名風格。
但是不管你如何定義屬性名，建議在一個合理的范圍內保持一致。這個范圍可能是組織(vendor)級別的，包(package)級別的，類(class)級別的，或者方法(method)級別的。
4.3. 方法
方法名則必須使用camelCase()風格來聲明。
什麼是PSR2定義代碼風格
代碼風格指南
本手冊是基礎代碼規范(PSR-1)的繼承和擴展。
為了盡可能的提升閱讀其他人代碼時的效率，下面例舉了一系列的通用規則，特別是有關於PHP代碼風格的。
各個成員項目間的共性組成了這組代碼規范。當開發者們在多個項目中合作時，本指南將會成為所有這些項目中共用的一組代碼規范。 因此，本指南的益處不在於這些規則本身，而在於在所有項目中共用這些規則。
RFC 2119中的必須(MUST)，不可(MUST NOT)，建議(SHOULD)，不建議(SHOULD NOT)，可以/可能(MAY)等關鍵詞將在本節用來做一些解釋性的描述。