Sidebar
PSRs are PHP Standards Recommendations. They are a standard and clearly defined way to do many common tasks.
PSR-0 - Autoloading Standard (This is not in use any more - you should use PSR-4.)
PSR-1 - Basic Coding Standard
It comprises what should be considered the standard coding elements that are required to ensure a high level of technical interoperability between shared PHP code
PSR-2 - Coding Style Guide
It considers PSR-1 and it is intended to reduce cognitive friction when scanning code from different authors. It does so by enumerating a shared set of rules and expectations about how to format PHP code.
- Use spaces, not tabs (4 spaces = 1 tab)
- The
namespace ...should be on its own line - The closing
?>must not be present, for files containing only PHP - PHP keywords (
true,false,null) must always be in lower case - The
extendsandimplementsmust be on the same line as the class name - The opening bracket must go on its own (new) line
- You must always provide a
public/protected/privatefor all object properties. Same for methods. - There must be exactly one space after the comma between method or function parameters, and no space before the comma
- Function and method parameters may be spread over several lines, if you wish
PSR-3 - Logger Interface
It describes a common interface for logging libraries
PSR-4 - Autoloading Standard
It describes a specification for autoloading classes from file paths. <NamespaceName>(<SubNamespaceNames>)*<ClassName>
PSR-4 is often used with Composer's composer.json to help with autoloading of PHP classes.
{
"autoload": {
"psr-4": {"": "src/"}
}
}
PSR-5 - PHPDoc Standard (Draft)
The main purpose of this PSR is to provide a complete and formal definition of the PHPDoc standard.
PSR-6 - Caching Interface
The goal of this PSR is to allow developers to create cache-aware libraries that can be integrated into existing frameworks and systems without the need for custom development
PSR-7 explained: HTTP Message Interface
It describes common interfaces for representing HTTP messages as described in RFC 7230 and RFC 7231 The PSR-7 bridge converts HttpFoundation objects from and to objects implementing HTTP message interfaces defined by the PSR-7. Better just use HTTP foundation
PSR-11 - Container Interface
It describes a common interface for dependency injection containers. The goal is to standardize how frameworks and libraries make use of a container to obtain objects and parameters (called entries in the rest of this document)
PSR-12 - Extended Coding Style Guide (Draft)
PSR-13 - Hypermedia Links
It describes common interfaces for representing a hypermedia link
PSR-14 - Event Manager
It describes common interfaces for dispatching and handling events
PSR-15 - HTTP Server Request Handlers
It describes common interfaces for HTTP server request handlers and HTTP server middleware components that use HTTP messages
PSR-16 - Simple Cache
It describes a simple yet extensible interface for a cache item and a cache drive
PSR-17 - HTTP Factories
It describes a common standard for factories that create PSR-7 compliant HTTP objects.
PSR-18 - HTTP Client
It describes a common interface for sending HTTP requests and receiving HTTP responses
PHPCS Fixer (sensiolabs): By default the PSR1 and PSR2 rules are used. Also you can use rule: @Symfony
The PHP.net wiki: To track internal development of PHP Before features can be added to PHP or before any breaking changes can occur, the change must first go through the Request for Comments (RFC) process.
Symfony project implements lots of PHP-FIG PSR standards, such as PSR-2 (code styling), PSR-3 (Logger interface), PSR-4 (autoloader), PSR-6 (caching interface) and PSR-16 (simple cache).
And also: PSR-11
PSR-11 defines a simple API that service containers must implement. In practice, this standard won't impact your existing Symfony applications. For starters, the public API only defines two methods called get() and has() which are named and behave in the same way as the Symfony methods that you know and use.
Page Tools
