Once upon a time, at a conference, the lead developers from a selection of frameworks sat down in the same room and agreed some standards for all their projects to use. The aim was to make PHP frameworks and libraries easier to combine for users. That is when php-fig: the PHP Framework Interop Group was born. This group of awesome individuals oversee the PHP Standards Recommendations (PSRs).


The PHP Standard Recommendation (PSR) is a PHP specification published by the PHP Framework Interoperability Group (PHP-FIG). It serves the standardization of programming concepts in PHP. The aim is to enable interoperability of components. The PHP-FIG is formed by several PHP frameworks founders.

PSR-0 & PSR-4

These describe a specification for auto loading classes from file paths. PSR-0 and PSR-4 are both standards concerning namespaces, class names and file paths. This PSR also describes where to place files that will be autoloaded according to the specification.

Auto loading

Autoloading is a functionality to help developers including  PHP classes automatically without writing cluttered include/require statements everywhere.
In PHP, class's definition is loaded with require or include statements in the files they are being called i.e., prior to using it as shown below. 

psr image 1

 

The above approach raises some issues as if we have tens of external classes to be used in a file and we start writing lines of require/include statements right at the beginning of a source file. 

To overcome this issue PHP 5 introduced the magic function __autoload() which is automatically called when your code references a class or interface that hasn’t been loaded yet.

psr image 2

 

Here’s an example of a basic __autoload() implementation: 

psr_image3

 

The major drawback to the __autoload() function is that you can only provide one autoloader with it. PHP 5.1.2 introduced another autoloading function (spl_autoload_register) for coping with __autoload 's limitation. 

The introduction of spl_autoload_register() gave programmers the ability to create an autoload chain, a series of functions that can be called to try and load a class or interface. 

For example:
 

psr_image4psr_image5

 

Autoloading was  such a great idea that every project started to use it. Inevitably everyone created their own version of autoloader as uniform standards were lacking. Clearly, PHP desperately needed a standard for autoloader, which is how PSR-0 was born. The latest accepted autoloader standard is PSR-4. 

PSR-0 (Autoloading Standard)

Overview of PSR-0:

  • 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 are suffixed with .php when loading from the file system.
  • Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lowercase and uppercase.

Examples:

\Doctrine\Common\IsolatedClassLoader =>
/path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php

\Symfony\Core\Request =>
/path/to/project/lib/vendor/Symfony/Core/Request.php

PSR-4 (Autoloading Standard)

Overview of PSR-4:

  • The term “class” refers to classes, interfaces, traits, and other similar structures.
  • A fully qualified class name has the following form:
    \<NamespaceName>(\<SubNamespaceNames>)*\<ClassName>
  • The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”.
  • The fully qualified class name MAY have one or more sub-namespace names.
  • The fully qualified class name MUST have a terminating class name.
  • Underscores have no special meaning in any portion of the fully qualified class name.
  • Alphabetic characters in the fully qualified class name MAY be any combination of lowercase and uppercase.
  • All class names MUST be referenced in a case-sensitive fashion.

Example for PSR-4 based Autoloading using Composer:

  • Consider the following directory structure to achieve PSR-4 based autoloading using composer.
psr_image6
  • Create a composer.json file using composer init. If not, you can create one manually now in your project’s root.
psr_image7
  • Set up PSR4 autoloading by editing the composer.json file as shown below:
psr_image8
  • Here, CodeCourse is a vendor name of your application, you can use this name while namespacing files inside of your src directory ,such as:
     psr_image9

    Or

psr_image10

         etc,

  • And src is your application’s directory that you want to autoload.
  • Next, open up your terminal and type in the following command to install autoloading files in your project.This will generate the vendor directory and autoload.php file inside of it.
psr_image11
  • Let’s first create a couple of classes inside of the CodeCourse directory.

Create AuthFilters.php inside CodeCourse/Filters

psr_image11

 

Create UserRepository.php inside CodeCourse/Repositories

psr_image12
  • Finally, create an index.php file to test it out and need to require once the autoload.php file once into your index.php file.
psr_image14

 

PSR-1 & PSR-2

PSR-1 and PSR-2 are useful for PHP coding standards. PSR-1 mainly focuses on the basic coding standard for PHP whereas PSR-2 is more like an expanded version of PSR-1. PSR-1 lists a set of simple rules for naming conventions and PSR-2 provides a more comprehensive coding style guide. 

PSR-1 (Basic Coding Standard)

Overview of PSR-1:

  • Only <?php or <?= are allowed for PHP tags.
  • Class names must be defined in UpperCamelCase.
  • Class variables must be defined in camelCase.
  • Class constants must be defined in UPPER_SNAKE_CASE.
  • Method names must be defined in camelCase.
  • 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. I.e.,
psr_image15

The above example causes a side effect, i.e., loading a file named “file.php”.

  • Files must be in UTF-8 without BOM(Byte Order Mark).
  • Namespaces and class names must follow the standards in PSR-0 and PSR-4.

Here is an example that illustrates the basic naming conventions for properties, classes, and methods.

psr_image16

 

PSR-2 (Coding Style Guide)

Overview of PSR-2:

  • You must follow the PSR-1 coding standards.
  • 4 spaces must be used for indents. Using tabs is not allowed.
  • There is no limit to line length, but it should be under 120 characters, and best if under 80.
  • There must be one blank line after namespace declaration and there must be one blank line after the block of use declaration.
  • Opening curly braces for classes and methods must go on the next line and closing curly braces must go on the line after the body.
  • Methods and properties must be defined with abstract/final first, followed with public/protected, and finally static keyword.
  • You must not put a newline before curly braces in conditional statements.
  • You must not put any spaces before ( and ) in conditional statements.
  • An example for defining classes:
  • You must open the curly braces on the new line and the extends and the implements keyword must be used in a single line.
psr_image17

 

If there are multiple interfaces to implement, then you can write the interface names in the new line as shown below:

psr_image18

 

Example to show how methods are defined in PHP:
While defining the methods, the arguments should be written in the same line. Also, you must not put any whitespaces before commas in arguments, and you must put one whitespace after them.

psr_image19

 

If there are many number of arguments, then they can be written in newline one after the other:

psr_image20

 

When defining methods, you must have either one of public/protected/private and abstract/final. The visibility modes come after the abstract/final keyword, if used. static is the last modifier.

psr_image21

Conditional Statements

  • You must put one whitespace before (
  • You must not put any whitespaces after (
  • You must not put any whitespaces before )
  • You must put one whitespace after )
  • use elseif rather than else if.

Example to show the difference between elseif and else if:
Interpretation of elseif:

psr_image22

 

Interpretation of else if:

psr_image23

 

For the switch statements, 

  • The curly braces must be opened in the same line where the switch statement is written.
  • The case body must be indented once from the case and the case must be indented once from the switch.
  • Use no break when break is not needed.
  • You can also use return instead of break.

Example:
 

psr_image24

 

Ankitha and SamvadaDec 24, 2019