PSR
PSR-0
A fully-qualified namespace and class must have the following structure \<Vendor Name>\(<Namespace>\)*<Class Name>
一個完全合格的 namespace (命名空間) 與 class (類別) 需要符合這樣的結構\<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
Each namespace must have a top-level namespace ("Vendor Name").
每個 namespace 需要有一個頂層的命名空間 (“提供者名稱(Vendor Name”)。
Each namespace can have as many sub-namespaces as it wishes.
如果需要的話，每個 namespace 皆可有多個子命名空間。
Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system.
當 namespace 若是從檔案系統載入時，其使用的分隔符號皆要轉換成 DIRECTORY_SEPARATOR 。
Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.
類別名稱 (class name) 中，每個底線符號 (“_”) 皆要轉換成 DIRECTORY_SEPARATOR 。因為底線(“_”)在 namespace 中是沒有意義的。
The fully-qualified namespace and class is suffixed with .php when loading from the file system.
從檔案系統所載入的合格 namespace 與 class 一定是 “.php” 結尾。
Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case.
Vendors name、namespace 以及 class name 所使用的字母可以由大小寫組成。
PSR-1
Files MUST use only <?php and <?= tags.
檔案中一定 (MUST) 只能使用 <?php 以及 <?= 標籤。Files MUST use only UTF-8 without BOM for PHP code.
PHP 程式的檔案編碼，一定 (MUST) 要用 “無 BOM 之 UTF-8″ 格式。
Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
檔案需要 (SHOULD) 在 宣告 symbols (classes, functions, constants, 等) 或是採用從屬效應(side-effects) (像是產生輸出，變動 .ini 的設定等) 中擇一處理，不需要 (SHOULD NOT) 二者都做。
Namespaces and classes MUST follow PSR-0.
命名空間以及類別一定 (MUST) 依循著 PSR-0 建議文件。
Class names MUST be declared in StudlyCaps.
類別名稱一定 (MUST) 是採用 大寫開始的駝峰大小寫命名法(StudlyCaps) 來宣告。
Class constants MUST be declared in all upper case with underscore separators.
類別中的宣告常數變數的名稱一定 (MUST) 是由全大寫字母以及底線符號組成。
Method names MUST be declared in camelCase.
函式名稱一定 (MUST) 是以 小寫開始的駝峰大小寫命名法(camelCase) 宣告。
PSR-2
Code MUST follow PSR-1.
程式碼一定 (MUST) 得依循 PSR-1。
Code MUST use 4 spaces for indenting, not tabs.
程式碼的縮排一定 (MUST) 是用四個空白，而非 tab。
每行的字數長度需 (SHOLD) 得少於 80 字元；一定 (MUST) 要將相對限制(soft limit) 設定在 120 字元；必不要 (MUST NOT) 寫到絕對限制 (hard limit)。There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of use declarations.
宣告 命名空間 (namespace) 之下一定(MUST) 要空一行，以及宣告 use 之下一定 (MUST) 也要空一行。
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
類別 (class) 所使用的成對花括號，一定(MUST) 要將開始的放在宣告的下一行，以及程式碼本體結束的下一行。
方法 (method) 所使用的成對花括號，一定(MUST) 要將開始的放在宣告的下一行，以及程式碼本體結束的下一行。
Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility.
所有屬性或是方法的可視屬性(visibility)一定(MUST) 要宣告， abstract 以及 final 一定(MUST) 是宣告在可視屬性之前； static 則一定(MUST) 是宣告在可視屬性之後。
Control structure keywords MUST have one space after them; method and function calls MUST NOT.
控制結構 (control structure) 的關鍵字一定(MUST) 要在其後加入一個空白；方法(Method) 與函式(Function)則一定不要(MUST NOT)。
Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
控制結構的開始(左)花括號一定(MUST) 要在宣告啟始的同一行，而結束(右)花括號則一定(MUST) 要在其程式碼本體結束的下一行。
Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.
控制結構中，用到括弧時，其開始(左)括弧之後與結束(右)括弧之前一定不要(MUST NOT) 有空白。
PSR-3
- The LoggerInterface exposes eight methods to write logs to the eight RFC 5424 levels (debug, info, notice, warning, error, critical, alert, emergency).
- A ninth method, log, accepts a log level as first argument. Calling this method with one of the log level constants MUST have the same result as calling the level-specific method. Calling this method with a level not defined by this specification MUST throw a Psr\Log\InvalidArgumentException if the implementation does not know about the level. Users SHOULD NOT use a custom level without knowing for sure the current implementation supports it.
- Every method accepts a string as the message, or an object with a __toString() method. Implementors MAY have special handling for the passed objects. If that is not the case, implementors MUST cast it to a string.
- The message MAY contain placeholders which implementors MAY replace with values from the context array.
- Placeholder names MUST correspond to keys in the context array.
- Placeholder names MUST be delimited with a single opening brace { and a single closing brace }. There MUST NOT be any whitespace between the delimiters and the placeholder name.
- Placeholder names SHOULD be composed only of the characters A-Z, a-z, 0-9, underscore _, and period .. The use of other characters is reserved for future modifications of the placeholders specification.
相關連結
- PHP-FIG — PHP Framework Interop Group
- 關於可維護的 PHP 專案：PHP-FIG 的 PSR-0、PSR-1、PSR-2
- PSR-0 Autoloading Standard
- PSR-1 Basic Coding Standard
- PSR-2 Coding Style Guide
- fig-standards/accepted/PSR-0.md at master · php-fig/fig-standards · GitHub
- fig-standards/accepted/PSR-1-basic-coding-standard.md at master · php-fig/fig-standards · GitHub
- fig-standards/accepted/PSR-2-coding-style-guide.md at master · php-fig/fig-standards · GitHub
- 關於 PHP FIG Group 所制定的 PSR-0, PSR-1, PSR-2
