php fig psr 12

New blog, PSR-12 approval and Upgrading PSRs

After a long hiatus, we’re back with a new round of updates from the PHP-FIG.

New Blog

As you may have noticed, we’re now on a different platform. We’ve chosen to migrate away from the previous proprietary platform and to host directly our posts inside our site, directly under our control. We will add links at the top of all our older posts to the new copies here; if anyone still stumbles upon our posts on the previous platform, they will know where to find us from now on.

PSR-12 has beenВ approved

Since the last update, we’ve seen the approval of PSR-12, the Extended Coding Style. This PSR supersedes the old dear PSR-2, adapting it to all the new language features that we’ve got in the last years, and cleaning up a few inconsistencies. It was a long time coming, since the working group had some troubles along the line, but we finally published it.

You will find that many libraries have already PSR-12 compliant releases, like PHP_CodeSniffer and EasyCodingStandard, while others are following suit, like PHP-CS-Fixer.

Pushing PSR interfaces forward

In the meantime, we’re discussing a difficult matter in our mailing list: how to upgrade PSRs.

This is an argument that made the round inside the PHP-FIG many times in the past, and still needs a proper solution. Stay tuned to hear more from us on this regard!

Источник

Php fig psr 12

Extended Coding Style Guide Meta Document

This document describes the process and discussions that led to the Extended Coding Style PSR. Its goal is to explain the reasons behind each decision.

PSR-2 was accepted in 2012 and since then a number of changes have been made to PHP, most notably recent changes for PHP 7, which have implications for coding style guidelines. Whilst PSR-2 is very comprehensive of PHP functionality that existed at the time of writing, new functionality is very open to interpretation. PSR-12 seeks to provide a set way that both coding style tools can implement, projects can declare adherence to and developers can easily relate on between different projects for these coding style reducing cognitive friction.

PSR-2 was created based upon the common practices of the PHP-FIG projects at the time but ultimately this meant it was a compromise of many of the different projects’ guidelines. The repercussions of projects changing their coding guidelines to align with PSR-2 (Almost all projects do align with PSR-1, even if it is not explicitly stated) were seen to be too great (losing git history, huge changesets and breaking existing patches/pull requests).

PSR-2 required adopters to reformat large amounts of existing code which stifled adoption. To help alleviate this issue with PSR-12, we have taken a more prescriptive approach and defined the standards for new language features as they are released.

However it is for a lack of wanting to be dictatorial that we will aim to apply PSR-2 styling, rationale and stances (Described in Section 4, Approaches) in PSR-12 instead of establishing new conventions.

This PSR shares the same goals as PSR-2.

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. 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.

This PSR is an extension of PSR-2, and therefore also an extension of PSR-1. The basis of PSR-12 is PSR-2 and therefore a list of differences is provided below to assist with migration but it should be considered as an independent specification.

This PSR will include coding style guidelines related to new functionality added to PHP after the publication of PSR-2; this includes PHP 5.5, PHP 5.6 and PHP 7.0. This PSR will also include clarifications on the text of PSR-2, as described in the PSR-2 Errata.

It is not the intention of this PSR to add entirely new coding style guidelines. PSR-12 will also not change anything stipulated in PSR-1 and PSR-2.

The overarching approach is to attempt to apply existing PSR-2 styling and rationale to new functionality as opposed to establishing new conventions.

4.1. Strict Types Declarations

There was a discussion about whether or not strict types should be enforced in the standard https://github.com/cs-extended/fig-standards/issues/7. All were in agreement we should only use a MUST or MUST NOT statement and avoid the use of a SHOULD statement and nobody wanted to say that strict types could not be declared. The discussion was whether it should be considered a coding style item which should be covered or whether it was out of scope and it was decided to be out of scope of a coding style guide.

4.2. Finally and Return Types Declaration Spacing

Numerous different options were suggested and they can be seen here for return type declarations or here for finally blocks and the current implementation was chosen due to consistency with other parts of the PSR-12 specification that came from PSR-2.

4.3. Enforcing short form for all type keywords

PHP 7.0 introduced scalar types declaration which does not support long type aliases. Therefore it makes sense to enforce primary short type forms to be used to have uniform syntax and prevent possible confusion.

In order to settle things using data, survey was conducted and responses from 142 people including 17 project representatives were gathered:

4.4.1. PHP-FIG Representative Results

4.4.2. General non-representative voters

4.5. Multiline Function Arguments Mixed With Multiline Return

A potential readability issue was raised on the mailing list. We reviewed options for changes to the specification that could provide better readability and the floated option was to require a blank line after the opening bracket of a function if the arguments and the return are both multiline. Instead it was pointed out that this specification already allows you to decide where you’d like to add blank lines and so we will leave it to the implementors to decide.

5. Changelog from PSR-2

Please note this changelog is not a verbose list of changes from PSR-2 but highlights the most notable changes. It should be considered a new specification and therefore you should read the specification for a full understanding of its contents.

5.2. Clarifications and Errata

6.3. Working Group Members:

Note: Order descending chronologically.

Источник

Php fig psr 12

Extended Coding Style Guide

The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 2119.

This specification extends, expands and replaces PSR-2, the coding style guide and requires adherence to PSR-1, the basic coding standard.

Like PSR-2, the intent of this specification 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. This PSR seeks to provide a set way that coding style tools can implement, projects can declare adherence to and developers can easily relate to between different 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 the sharing of those rules.

PSR-2 was accepted in 2012 and since then a number of changes have been made to PHP which has implications for coding style guidelines. Whilst PSR-2 is very comprehensive of PHP functionality that existed at the time of writing, new functionality is very open to interpretation. This PSR, therefore, seeks to clarify the content of PSR-2 in a more modern context with new functionality available, and make the errata to PSR-2 binding.

Previous language versions

Throughout this document, any instructions MAY be ignored if they do not exist in versions of PHP supported by your project.

This example encompasses some of the rules below as a quick overview:

2.1 Basic Coding Standard

Code MUST follow all rules outlined in PSR-1.

The term ‘StudlyCaps’ in PSR-1 MUST be interpreted as PascalCase where the first letter of each word is capitalized including the very first letter.

All PHP files MUST use the Unix LF (linefeed) line ending only.

All PHP files MUST end with a non-blank line, terminated with a single LF.

There MUST NOT be a hard limit on line length.

The soft limit on line length MUST be 120 characters.

Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than 80 characters each.

There MUST NOT be trailing whitespace at the end of lines.

Blank lines MAY be added to improve readability and to indicate related blocks of code except where explicitly forbidden.

There MUST NOT be more than one statement per line.

Code MUST use an indent of 4 spaces for each indent level, and MUST NOT use tabs for indenting.

2.5 Keywords and Types

All PHP reserved keywords and types [1][2] MUST be in lower case.

Any new types and keywords added to future PHP versions MUST be in lower case.

3. Declare Statements, Namespace, and Import Statements

The header of a PHP file may consist of a number of different blocks. If present, each of the blocks below MUST be separated by a single blank line, and MUST NOT contain a blank line. Each block MUST be in the order listed below, although blocks that are not relevant may be omitted.

When a file contains a mix of HTML and PHP, any of the above sections may still be used. If so, they MUST be present at the top of the file, even if the remainder of the code consists of a closing PHP tag and then a mixture of HTML and PHP.

When the opening tag is on the first line of the file, it MUST be on its own line with no other statements unless it is a file containing markup outside of PHP opening and closing tags.

Import statements MUST never begin with a leading backslash as they must always be fully qualified.

The following example illustrates a complete list of all blocks:

Compound namespaces with a depth of more than two MUST NOT be used. Therefore the following is the maximum compounding depth allowed:

And the following would not be allowed:

When wishing to declare strict types in files containing markup outside PHP opening and closing tags, the declaration MUST be on the first line of the file and include an opening PHP tag, the strict types declaration and closing tag.

Источник

PSR-12: Extended Coding Style

1. Summary

This document describes the process and discussions that led to the Extended Coding Style PSR. Its goal is to explain the reasons behind each decision.

2. Why Bother?

PSR-2 was accepted in 2012 and since then a number of changes have been made to PHP, most notably recent changes for PHP 7, which have implications for coding style guidelines. Whilst PSR-2 is very comprehensive of PHP functionality that existed at the time of writing, new functionality is very open to interpretation. PSR-12 seeks to provide a set way that both coding style tools can implement, projects can declare adherence to and developers can easily relate on between different projects for these coding style reducing cognitive friction.

PSR-2 was created based upon the common practices of the PHP-FIG projects at the time but ultimately this meant it was a compromise of many of the different projects’ guidelines. The repercussions of projects changing their coding guidelines to align with PSR-2 (Almost all projects do align with PSR-1, even if it is not explicitly stated) were seen to be too great (losing git history, huge changesets and breaking existing patches/pull requests).

PSR-2 required adopters to reformat large amounts of existing code which stifled adoption. To help alleviate this issue with PSR-12, we have taken a more prescriptive approach and defined the standards for new language features as they are released.

However it is for a lack of wanting to be dictatorial that we will aim to apply PSR-2 styling, rationale and stances (Described in Section 4, Approaches) in PSR-12 instead of establishing new conventions.

3. Scope

3.1. Goals

This PSR shares the same goals as PSR-2.

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. 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.

This PSR is an extension of PSR-2, and therefore also an extension of PSR-1. The basis of PSR-12 is PSR-2 and therefore a list of differences is provided below to assist with migration but it should be considered as an independent specification.

This PSR will include coding style guidelines related to new functionality added to PHP after the publication of PSR-2; this includes PHP 5.5, PHP 5.6 and PHP 7.0. This PSR will also include clarifications on the text of PSR-2, as described in the PSR-2 Errata.

3.2. Non-Goals

It is not the intention of this PSR to add entirely new coding style guidelines. PSR-12 will also not change anything stipulated in PSR-1 and PSR-2.

4. Approaches

The overarching approach is to attempt to apply existing PSR-2 styling and rationale to new functionality as opposed to establishing new conventions.

4.1. Strict Types Declarations

There was a discussion about whether or not strict types should be enforced in the standard https://github.com/cs-extended/fig-standards/issues/7. All were in agreement we should only use a MUST or MUST NOT statement and avoid the use of a SHOULD statement and nobody wanted to say that strict types could not be declared. The discussion was whether it should be considered a coding style item which should be covered or whether it was out of scope and it was decided to be out of scope of a coding style guide.

4.2. Finally and Return Types Declaration Spacing

Numerous different options were suggested and they can be seen here for return type declarations or here for finally blocks and the current implementation was chosen due to consistency with other parts of the PSR-12 specification that came from PSR-2.

4.3. Enforcing short form for all type keywords

PHP 7.0 introduced scalar types declaration which does not support long type aliases. Therefore it makes sense to enforce primary short type forms to be used to have uniform syntax and prevent possible confusion.

4.4. Public Survey

In order to settle things using data, survey was conducted and responses from 142 people including 17 project representatives were gathered:

4.4.1. PHP-FIG Representative Results

4.4.2. General non-representative voters

4.5. Multiline Function Arguments Mixed With Multiline Return

A potential readability issue was raised on the mailing list. We reviewed options for changes to the specification that could provide better readability and the floated option was to require a blank line after the opening bracket of a function if the arguments and the return are both multiline. Instead it was pointed out that this specification already allows you to decide where you’d like to add blank lines and so we will leave it to the implementors to decide.

5. Changelog from PSR-2

Please note this changelog is not a verbose list of changes from PSR-2 but highlights the most notable changes. It should be considered a new specification and therefore you should read the specification for a full understanding of its contents.

5.1. New Statements

5.2. Clarifications and Errata

6. People

6.1. Editor:

6.2. Sponsor:

6.3. Working Group Members:

6.4. Special Thanks

7. Votes

8. Relevant Links

Note: Order descending chronologically.

Источник