PHP-FIG 與 PSR – PHP Coding Standard

受到近年 Ruby 等新語言急起直追影響, PHP 世界的開發者終於提起勁來,
想要解決 PHP 標準過於鬆散,開發者之間各自為政無法合作的局面。

PHP-FIG 在 2009 年 php|tek 開發者大會中成立,旨在制定一些編程標準,
讓不同人寫的 Framework 或 Library 能互相組合使用,
從而避免 “Reinvent the wheel” 浪費開發時間。

未知道它們是甚麼前 先解釋這兩個奇怪的縮寫

PHP-FIG = PHP Framework Interoperability Group
PSR = PHP Specification Request

PSR 由 PHP-FIG 的成員共同編寫,並投票表決通過。

截至目前已經通過了 5 份 PSR:

PSR-0
Aims to provide a standard file, class and namespace convention to allow plug-and-play code.
PSR-1
Aims to ensure a high level of technical interoperability between shared PHP code.
PSR-2
Provides a Coding Style Guide for projects looking to standardize their code.
PSR-3
Describes a common interface for logging libraries.
PSR-4
A more modern take on autoloading reflecting advances in the ecosystem.

這 5 份 PSR 已經包括了由 Namespace 制定,Coding Style, Naming Conventions 等的標準。
文中所用的 “MUST”, “SHOULD”, “MAY” 等詞語遵從 RFC2119 標準。

PSR-0 制定了 Namespace 命名規則,以便使用 Class Autoloader (將於 PSR-4 再詳細提及)。

PSR-1 和 PSR-2 主要是 Coding Style & Standard
只是 PSR-1 主要提及 Variable/Class Naming,File Format 等會影響程式實際使用的問題。
而 PSR-2 主要是外觀,例如 Indentation、Spacing 等的標準。

PSR-3 制定 Logger 的 Interface,而 PSR-4 進一步定義 Autoloader 相關的標准。

只挑一點比較有趣的看看:

PSR-0:

  • Each namespace must have a top-level namespace (“Vendor Name”).
    所有 Namespace 必須有 Top-level 的 Vendor Name
    例如 TigerWorkshop\Acl
  • Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system.
    Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.
    “namespace separator” 和 “underscore” 會被 Autoload 轉換為 DIRECTORY_SEPARATOR (Windows 下為 \ , *nix-like 下為 / )

PSR-1:

  • Files MUST use only <?php and <?= tags.
    <?= 以外的 Short-tag 不能使用, <? echo “123” ?> 的用法被禁止
  • 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.
    這個很有趣,每個檔案建議 只定義符號 或 只作出其他操作,不能同時做兩者。換句話說這樣寫在同一個檔案是不被建議的: 

    這一條規貼應該是要確保 M-V-C 分離,不要混雜在一起。
  • Class names MUST be declared in StudlyCaps.
    Class constants MUST be declared in all upper case with underscore separators.
    Method names MUST be declared in camelCase.
    這三條在 Java-like 的 OOP 語言大約是慣例了
  • Code written for 5.2.x and before SHOULD use the pseudo-namespacing convention of Vendor_ prefixes on class names.
    PHP 5.2.x 以下的版本,使用 _ 作 “偽 Namespace”
    (可以的話直接不支援好了)

PSR-2:

  • Code MUST use 4 spaces for indenting, not tabs.
    怎麼會… 我一直是比較喜歡用 Tab
  • All PHP files MUST use the Unix LF (linefeed) line ending.
    Windows 下的 \r\n 需要轉為 \n
  • All PHP files MUST end with a single blank line
  • The closing ?> tag MUST be omitted from files containing only PHP.
    現在比較流行用 Comment 結束,一來避免 ?> 之後的 Whitespace 造成 “Header already sent”,二來可以較易發易不完成的檔案
  • There MUST NOT be trailing whitespace at the end of non-blank lines.
    偏執狂可能要發作了…
  • Using only spaces, and not mixing spaces with tabs
    這簡直是編程界的常識啊!

    TabsSpacesBoth

  • PHP keywords MUST be in lower case.
    The PHP constants true, false, and null MUST be in lower case.
    糟糕… 我反而習慣用全大寫的
  • Visibility MUST be declared on all properties.
    雖然預設是 public,但不能懶惰了
  • Control structure keywords MUST have one space after them; method and function calls MUST NOT.
    只有 Control structure 的 keyword 後面要有 Space,其他都不能有
  • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.即是除了 Control Structure 的 Brace 放在同一行,其他的都必需換行
  • The body of each structure MUST be enclosed by braces.
    只有一行的 Control Structure 都不能省略 Brace
  • 總合以上兩點,PSR-2 建議的 Coding Style 應該是 K&R Style 的變體:1TBS
  • 還有很多關於哪裡放 Space 哪裡不放的,跟一般使用習慣相同就不提了。

PSR-3 和 PSR-4 因為我還沒實際寫過 Logger 和 Autoloader,之後有需要再研究。

當然 PHP-FIG 製定的 PSR 只是「建議」,
私人 Project 其實那一種 Coding Standard 都不差 (只要有就好…),那當然要在合理範圍內統一。

但如果自己或團隊還未有統一的 Standard,這會是相當好的參考資料。

Leave a Reply

Your email address will not be published.