資訊專欄INFORMATION COLUMN
摘要：目前已表決通過了套標準，已經得到大部分框架的支持和認可。類中的常量所有字母都必須大寫，單詞間用下劃線分隔方法名稱必須符合式的小寫開頭駝峰命名規范。日志接口規范詳見自動加載規范詳見緩存接口規范詳見消息接口規范詳見，暫無中文翻譯
PHP-FIG
在說啥是PSR-[0-4]規范的之前，我覺得我們有必要說下它的發明者和規范者：PHP-FIG。就是這個聯盟組織發明和創造了PSR-[0-4]規范
FIG 是 Framework Interoperability Group（框架可互用性小組）的縮寫，由幾位開源框架的開發者成立于
2009 年，從那開始也選取了很多其他成員進來，雖然不是 “官方” 組織，但也代表了社區中不小的一塊。
項目的目的在于：通過框架作者或者框架的代表之間討論，以最低程度的限制，制定一個協作標準，各個框架遵循統一的編碼規范，避免各家自行發展的風格阻礙了
PHP 的發展，解決這個程序設計師由來已久的困擾。目前已表決通過了 6 套標準，已經得到大部分 PHP 框架的支持和認可。
1 基礎編碼規范 PSR-1
2 編碼風格規范 PSR-2
3 日志接口規范 PSR-3
4 自動加載規范 PSR-4
6 緩存接口規范 PSR-6
7 HTTP 消息接口規范
PHP代碼文件 必須 以 或 標簽開始；
PHP代碼文件 必須 以 不帶 BOM 的 UTF-8 編碼；
PHP代碼中 應該 只定義類、函數、常量等聲明，或其他會產生 副作用 的操作（如：生成文件輸出以及修改 .ini配置文件等），二者只能選其一；
「副作用」(side effects) 一詞的意思是，僅僅通過包含文件，不直接聲明類、函數和常量等，而執行的邏輯操作。
「副作用」包含卻不僅限于：生成輸出
直接的 require 或 include
連接外部服務
修改 ini 配置
拋出錯誤或異常
修改全局或靜態變量
讀或寫文件等
以下是一個 反例，一份包含「函數聲明」以及產生「副作用」的代碼：
";
// 聲明函數
function foo()
{
// 函數主體部分
}
下面是一個僅包含聲明的示例文件；即應提倡的例子：
命名空間以及類 必須 符合 PSR 的自動加載規范：[PSR-4]() 中的一個；
類的命名必須 遵循 StudlyCaps 大寫開頭的駝峰命名規范；
類的屬性命名 可以 遵循：
大寫開頭的駝峰式 ($StudlyCaps)
小寫開頭的駝峰式 ($camelCase)
下劃線分隔式 ($under_score)
本規范不做強制要求，但無論遵循哪種命名方式，都 應該 在一定的范圍內保持一致。這個范圍可以是整個團隊、整個包、整個類或整個方法。
類中的常量所有字母都 必須 大寫，單詞間用下劃線分隔；
方法名稱 必須 符合 camelCase 式的小寫開頭駝峰命名規范。
編碼風格規范代碼必須遵守 PSR-1。
代碼必須使用4個空格來進行縮進，而不是用制表符。
一行代碼的長度不建議有硬限制；軟限制必須為120個字符，建議每行代碼80個字符或者更少。
在命名空間(namespace)的聲明下面必須有一行空行，并且在導入(use)的聲明下面也必須有一行空行。
類(class)的左花括號必須放到其聲明下面自成一行，右花括號則必須放到類主體下面自成一行。
方法(method)的左花括號必須放到其聲明下面自成一行，右花括號則必須放到方法主體的下一行。
$b) { $foo->bar($arg1); } else { BazClass::bar($arg2, $arg3); } } final public static function bar() { // 方法主體 } }
所有的屬性(property)和方法(method)必須有可見性聲明；抽象(abstract)和終結(final)聲明必須在可見性聲明之前；而靜態(static)聲明必須在可見性聲明之后。
在控制結構關鍵字的后面必須有一個空格；而方法(method)和函數(function)的關鍵字的后面不可有空格。
控制結構的左花括號必須跟其放在同一行，右花括號必須放在該控制結構代碼主體的下一行。
控制結構的左括號之后不可有空格，右括號之前也不可有空格。
日志接口規范詳見
自動加載規范詳見
緩存接口規范詳見
HTTP 消息接口規范詳見，暫無中文翻譯
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/28521.html
摘要：的使命是實現框架之間的互操作性。個人和官方都認為開發者應該遵循更為嚴格的代碼標準，在現代的生態系統中，風格統一，可以更好的讓其他開發者理解代碼。記錄的消息用于診斷檢查和排除應用中的操作穩定性和性能方面的問題。 原文是在我自己博客中，小伙伴也可以點閱讀原文進行跳轉查看，還有好聽的背景音樂噢~ ????PSR是PHP Standards Recommendation的簡稱，意為PHP推薦標...
摘要：公認規范總結規范中文版大部分來源翻譯部分包含例子，附錄包含了一些規范的實現基本編碼標準編碼風格指南日志接口規范自動加載規范規范英文版未使用草案已棄用規范原理實現實現自動加載實現原理資料來源與參考 PSR公認規范總結 PSR規范中文版(大部分來源google翻譯)(cn) 部分psr包含例子，附錄包含了一些規范的實現 PSR-1：基本編碼標準 PSR-2：編碼風格指南 PSR-3：日志...
摘要：注本文算是筆者對規范翻譯學習筆記，之后會陸續翻譯剩余的規范，可能翻譯的有錯誤的地方，希望讀者能夠指正，非常感謝什么是是標準建議的簡寫，是由組織框架交互操作組織提出。的工作是尋找項目之間的共性，以及讓開發者能更好協同工作的方式。 注:本文算是筆者對PSR規范翻譯/學習筆記，之后會陸續翻譯剩余的規范，可能翻譯的有錯誤的地方，希望讀者能夠指正，非常感謝. 什么是PSR？ ? ??? PSR是...
摘要：標準規范簡介是的簡寫，由組織制定的規范，是開發的實踐標準。具體標準有有了統一編碼風格規范，更有利于查看和學習各個框架或類庫，不不需要每次都適應新的編碼風格。同時在開發團隊內部使用統一的編碼規范更有利于代碼審查版本控制團隊內部交流。 PHP 標準規范 PSR PSR 簡介 PSR 是 PHP Standard Recommendations 的簡寫，由 PHP FIG 組織制定的 PHP...
摘要：是一系列關于開發的規范，分有好幾個版本，自己學的也較為膚淺，但還是希望能時常查看規范，為了方便記憶和遵循，我把關鍵詞為必須的撿拾出來，做個簡單地必要規范的記錄。所有文件必須使用作為行的結束符。 PSR是一系列關于PHP開發的規范，分有好幾個版本，自己學的也較為膚淺，但還是希望能時常查看規范，為了方便記憶和遵循，我把關鍵詞為必須的撿拾出來，做個簡單地必要規范的記錄。(就是個搬磚的。。。)...
閱讀 1076·2021-10-14 09:42
閱讀 1369·2021-09-22 15:11
閱讀 3285·2019-08-30 15:56
閱讀 1243·2019-08-30 15:55
閱讀 3612·2019-08-30 15:55
閱讀 889·2019-08-30 15:44
閱讀 2028·2019-08-29 17:17
閱讀 2071·2019-08-29 15:37
