Uncategorized

PSR’s | PHP Specification Request | Proposing Specification Request

Introduction :

PSR, a PHP Specification Request, is an attempt to standardise the way people use PHP in the hope that different sets of code libraries will work together. I am writing it down here, just to make everyone understand why this is necessary, and the objective behind standardizing the way everyone writes code. This is a must, when you are trying to write your Plugin or any class; which are pluggable. These specifications have been introduces by the body called PHP-FIG; PHP Framework Interoperability Group. The focus was to create standards for every developer (call it contributor), so that classes/packages/plugins can be plugged in any where, to other frameworks as well. But later, they have started rolling out for every package. Composer, a Package management system; also considers these as guidelines. So let’s see what PSR talks about in it’s 5 versions.

 1. PSR-0 : Autoloading Standard

The following describes the mandatory requirements that must be adhered to for autoloader interoperability.

Mandatory

  • A fully-qualified namespace and class must have the following structure \<Vendor Name>\(<Namespace>\)*<Class Name>
  • Each namespace must have a top-level namespace (“Vendor Name”).
  • Each namespace can have as many sub-namespaces as it wishes.
  • 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.
  • The fully-qualified namespace and class is suffixed with .php when loading from the file system.
  • Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case.

 

2. PSR-1 : Basic Coding Standard

Overview

  • Files MUST use only <?php and <?= tags.
  • Files MUST use only UTF-8 without BOM for PHP code.
  • 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.
  • Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0, PSR-4].
  • 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.

 

3. PSR-2 : Coding Style Guide

This guide extends and expands on PSR-1, the basic coding standard.

The intent of this guide is 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.

The style rules herein are derived from commonalities among the various member projects. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.

Overview

  • Code MUST follow a “coding style guide” PSR [PSR-1].
  • Code MUST use 4 spaces for indenting, not tabs.
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
  • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations.
  • 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.
  • 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.
  • Control structure keywords MUST have one space after them; method and function calls 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.
  • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

4. PSR-3 : Logger Interface

This document describes a common interface for logging libraries.

The main goal is to allow libraries to receive a Psr\Log\LoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The word implementor in this document is to be interpreted as someone implementing the LoggerInterface in a log-related library or framework. Users of loggers are refered to as user.

For More details, check out : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

5. PSR-4 : Autoloader

Overview

This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.

Specification

  1. The term “class” refers to classes, interfaces, traits, and other similar structures.
  2. A fully qualified class name has the following form:\<NamespaceName>(\<SubNamespaceNames>)*\<ClassName>
    1. The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”.
    2. The fully qualified class name MAY have one or more sub-namespace names.
    3. The fully qualified class name MUST have a terminating class name.
    4. Underscores have no special meaning in any portion of the fully qualified class name.
    5. Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case.
    6. All class names MUST be referenced in a case-sensitive fashion.
  3. When loading a file that corresponds to a fully qualified class name …
    1. A contiguous series of one or more leading namespace and sub-namespace names, not including the leading namespace separator, in the fully qualified class name (a “namespace prefix”) corresponds to at least one “base directory”.
    2. The contiguous sub-namespace names after the “namespace prefix” correspond to a subdirectory within a “base directory”, in which the namespace separators represent directory separators. The subdirectory name MUST match the case of the sub-namespace names.
    3. The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name.
  4. Autoloader implementations MUST NOT throw exceptions, MUST NOT raise errors of any level, and SHOULD NOT return a value.

References :

Standard

Leave a comment