PHP PSR series specifications

PSR

is the abbreviation of PHP Standard Recommendation. It should actually be called PSRs, which is a series of recommended standards: currently passed specifications include PSR-0 (Autoloading Standard), PSR-1 (Basic Coding Standard), PSR-2 (Coding Style Guide), PSR-3 (Logger Interface), PSR-4 (Improved Autoloading). It is not an official PHP standard, but a series of standards extracted from well-known PHP projects such as Zend and Symfony2. Currently, more and more community projects have joined as members and follow this standard.

PHP-FIG — PHP Framework Interoperability Group is an organization that formulates PSRs development specifications. Its members are composed of many well-known PHP community projects. You can see the member list at the bottom of its official website homepage. These members develop specifications and implement them in their projects.

In fact, the contents of each PSR specification are very concise and clear, which is much better than those specifications that span dozens of pages.

PSR-0 (Autoloading Standard)

PSR-0 is the class automatic loading specification (original text: official website, GitHub). As of 2014-10-21, this specification is marked as Deprecated and replaced by PSR-4. Its content is very concise.

Content:

A fully qualified namespace and class name must have the following structure "()*"

Each namespace must have a top-level name Space ("Vendor Name")

Each namespace can have any number of sub-namespaces

Each namespace must be converted to an "operating system path separator" (DIRECTORY_SEPARATOR) when being loaded from the file system

Every "_" characters are converted to DIRECTORY_SEPARATOR in "Class Name". The "_" symbol has no clear meaning in the namespace

Namespace and class names that comply with the naming standards must end with ".php" to load the file

Vendor Name, namespace, and class names can be composed of uppercase and lowercase letters, where Namespaces and class names are case-sensitive to ensure multi-system compatibility

PSR-1 (Basic Coding Standard)

PSR-1 is the basic coding standard (original text: official website, GitHub). The content is also very concise, including the naming method of class files, class names, and class method names.

Content:

The source file must only use the two tags of

The encoding format of the php code in the source file must only use UTF-8 without BOM

One source file suggestion It is only used to make declarations (classes, functions, constants, etc.) or only to do some operations that cause side effects (for example: output information, modify .ini configuration files, etc.), but it should not be done at the same time.

Namespace And classes must comply with the PSR-0 standard

Class names must be written using StudlyCaps

Constants in the class must only consist of uppercase letters and underscores (_)

Method names must be written using cameCase

PSR-2 (Coding Style Guide )

PSR-2 is the coding style standard (original text: official website, GitHub). The content is slightly more, but it is still relatively concise. It is based on PSR-1 and includes relevant provisions for indentation, length of each line of code, line breaks, method visibility declarations, spaces, and method body brace wrapping.

Standard content:

Code must comply with PSR-1

Code must use 4 spaces for indentation instead of tabs

There should be no hard limit on the length of a line of code; the soft limit must be 120 Characters, it is recommended that each line of code should be 80 characters or less

There must be a blank line below the namespace declaration, and there must also be a blank line below the use declaration

The left curly brace of the class must be placed in its declaration The left curly brace must be placed on its own line below the class body. The left curly brace of the method must be placed on its own line below its declaration. The right curly brace must be placed on the next line of the method body.

All Properties and methods must have visibility declarations; abstract and final declarations must precede the visibility declaration; and static declarations must follow the visibility declaration. There must be a space after the structure control keyword; and when methods and functions are called There must be no spaces after it. The left curly brace of the structure control must be placed on the same line, and the right curly brace must be placed on the next line of the body of the structure control code. There must be no space after the left brace of the control structure, nor before the right brace. No spaces allowed

PSR-3(Logger Interface)

PSR-3 is the definition of the application log class through the interface (original text: official website, GitHub). The content is very simple, it is just an interface. Just quote the official sample code. Of course, in specific applications, as long as you follow this interface, you can definitely customize the corresponding implementation.

Basic content:

LoggerInterface exposes eight interfaces for recording eight levels of logs (debug, info, notice, warning, error, critical, alert, emergency).

The ninth method is log, which accepts the log level as the first parameter. Calling this method with a log level constant must have the same result as calling the specified level method directly. Calling this method with a log level not defined in this specification and unknown to the implementation must throw a PsrLogInvalidArgumentException. It is not recommended to use custom log levels unless you are very sure that the current class library supports it.

PSR-4 (Improved Autoloading)

PSR-4 is the improved version of the automatic loading specification (original text: official website, GitHub). It is the successor to the PSR-0 specification. It is compatible with any other autoloading specification, including PSR-0.

Content:

The term "class" is a general term; it includes classes, interfaces, traits and other similar structures;

The fully qualified class name should look like the following example: ()*< ;ClassName>

A fully compliant class name must have a top-level namespace (Vendor Name)

A fully compliant class name can have multiple sub-namespaces

A fully compliant class name should have a terminating class name

Underscore in There are no special meanings in fully compliant class names

Letters can be any combination of upper and lower case in fully compliant class names

All class names must be quoted in a case-sensitive manner

When deriving from fully compliant class names When loading a file:

In a fully compliant class name, a namespace prefix composed of one or several consecutive sub-namespaces (excluding the delimiter of the top-level namespace) corresponds to at least one base directory

in " The consecutive sub-namespace names after "namespace prefix" correspond to a subdirectory under the "base directory", where the namespace separator represents the directory separator. The subdirectory name must match the case of the subnamespace name. The terminating class name corresponds to a file ending in .php. The file name must match the case of the terminating class name

The implementation of the autoloader must not throw any exceptions or cause errors of any level; nor should it return a value