Problem/Motivation

PSR-2 and PSR-1 are accepted coding standards: https://github.com/php-fig/fig-standards/tree/master/accepted.

There is a list of peoples that voted (https://github.com/php-fig/fig-standards/blob/master/README.md):
- Nate Abele: Lithium
- Nils Adermann: phpBB
- Brett Bieber: PEAR, PEAR2
- Guilherme Blanco: Doctrine, Doctrine2, et al.
- Jordi Boggiano: Composer, Packagist
- Karma Dordrak: Zikula
- Paul Dragoonis: PPI, PPI2
- William Durand: Propel, Propel 2
- Andrew Eddie: Joomla
- Cal Evans: the community at large
- Larry Garfield: Drupal
- Paul M. Jones: Solar Framework, Aura Project
- Robert Lemke: FLOW3
- Larry Masters: CakePHP, CakePHP 2
- Evert Pot: SabreDAV
- Ryan Parman: Amazon Web Services SDK
- Fabien Potencier: Symfony, Symfony2
- Andre Romcke: eZ Publish
- Paul Scott: Chisimba, C4
- Phil Sturgeon: PyroCMS
- Kris Wallsmith: Assetic, Buzz
- Matthew Weier O'Phinney: Zend Framework, Zend Framework 2
- David Zülke: Agavi

The results of the vote were posted in the PHP-FIG group.

It seems like Drupal leads are in the list too. So the PSR-2 (and PSR-1 too) has some cons and pros, but for better interoperability between libraries I suggest to consider of using them for Drupal 8.

For example, I use (and I think many other peoples) other libraries. It is inconvenient for me change my code style, IDE settings and so on between Drupal and other libraries that supports PSR-2 like Symfony (http://symfony.com/doc/current/contributing/code/standards.html), ZF 2 etc. Personally I prefer some mix of Drupal and PSR-2 coding standards, but I need to follow common and modern trends in the PHP world.

What you think about that?

Resolution

According to #4, Drupal will not be adopting the PSR-2 and PSR-1
#9 gives more details,

Drupal originally implemented PSR-0 but has moved to support PSR-4 instead. see: https://www.drupal.org/node/1971198
Drupal does not support PSR-1 or PSR-2, Drupal has it's own rigid code standards.
Drupal supports the PSR-3. see: https://www.drupal.org/node/1289536

Comments

hinikato’s picture

As one more suggestion: keep current standard for files with functions but use PSR-2 for files with classes.

dcmouyard’s picture

FYI - I read somewhere (maybe IRC) that Drupal 8 will not be adopting PSR-1 or PSR-2. The current Drupal coding standards will not change.

sun’s picture

Status: Active » Closed (won't fix)
Issue tags: +Coding standards
gagarine’s picture

Category: feature » task
Status: Closed (won't fix) » Active

Arrrgh! Than mean I will have to change my IDE settings and habits when I switch from symphony to Drupal... As those two projects become closer it will make sens to use the same coding standards.

We can also benefit from tools developed for symphony/PSR-x like http://cs.sensiolabs.org/ . BTW with a tools like that it should be easy to change automatically the code style in all DO projects...

sun’s picture

Status: Active » Closed (won't fix)

Get a better IDE.

gagarine’s picture

@sun I'm sorry to say your answer is offensive and make you look arrogant. You made a tons of good works and I totally respect you, I wait the same for you. More than that it was discussed on IRC and their was perhaps good arguments against using PSR-2... but the two links you add didn't convince me. So I guess others peoples are going to re-open this bug.

AlessMascherpa’s picture

PSR-2, even it has good points, is not cool. Arguments are cleanly stated by Matt Farina in http://engineeredweb.com/blog/practical-problems-psr-2/ In short: "The web is wider than PHP". Also Coding style standards are very important for development, but offer little to real interoperability between projects.

For those curious about Drupal leads vote -> Larry Garfield's vote on that topic in the PHP standards discussion group: https://groups.google.com/d/msg/php-fig/c-QVvnZdMQ0/EHbiF_sCkDwJ

I'm glad that Drupal stays with his coding style standard, even I prefer camelCaseNames rather than underscore_names :)

Cheers
Alessandro.

ro-no-lo’s picture

My guess is Drupal until D10 or so will only adopt PSR-0 and maybe PSR-3.

A lot of core developers are still on their framework island. I personally, als long term drupaller, would prefer to switch between kohana, zend, drupal, symfony and feel visually in every source code at home, because of PSR-1 and PSR-2 acceptance.

Drupal 8 will be a mix of at least two or more coding standards, because of the libraries used. If you have to fix something in a library which may be taken from Yii you will roll eyes. Because their codeing standard is the worst I have ever seen. From the Yii project lead here: http://www.yiiframework.com/forum/index.php/topic/3667-coding-standard/

Regarding coding standards, I tend to be very frugal in writing code: no spacing around brackets and operators, no extra brackets enclosing single if-statements, and using tabs instead of spaces for indentation. Forgive me if these "bad" habits make you read the Yii code difficultly.

But trust me, I'm a professional programmer with a lot of experience working in big (with hundreds of people) and small teams. The so-called coding standards are always a set of loose standards in these circumstances. Things like the above three aspects never appear in any of these standards that I have experience with. I guess that's why my habit like this.

Time will tell. I vote for PSR-1 and PSR-2 for Drupal. (Even though I prefer the 2 spaces indents)

cosmicdreams’s picture

I found this page because I searched for PSR-2 today.

To those who stumble across this post and read through the comments. Here's a snapshot of Drupal's support for PSRs:

Drupal originally implemented PSR-0 but has moved to support PSR-4 instead. see: https://www.drupal.org/node/1971198
Drupal does not support PSR-1 or PSR-2, Drupal has it's own rigid code standards that can quickly and easily be used in modern IDEs such as PhpStorm.
Drupal supports the PSR-3. see: https://www.drupal.org/node/1289536

bojanz’s picture

As far as I can see, there's no incompatibility between Drupal's coding standards and PSR-1.

Only PSR-2 is the "problematic, won't fix" one.

timmillwood’s picture

Version: 8.0.x-dev » 9.x-dev
Status: Closed (won't fix) » Postponed

Honestly shocked to see D8 won't be officially PSR-1 or PSR-2, especially with the PHP-FIG endorsement of these standards from Crell (the Drupal representative).

It looks like we're already PSR-1 compliant but I think, like the components we're using, we should adopt PSR-2.

I am reopening, albeit as "Postponed" and moving to D9. It'd be awesome to get this into a point release of D8, but would need to evaluate the implications of updating coding standards in a point release. This has been done in other projects, for example Laravel 5.0 used PSR-1 + custom standards but Laravel 5.1 is now using PSR-2.

Crell’s picture

timmillwood: The Drupal FIG representative voted against PSR-2, not for it.

Our OOP code is, I believe, all PSR-1-friendly already but we should confirm that.

timmillwood’s picture

Priority: Major » Minor
Issue summary: View changes

@crell - Sorry for the missunderstanding

When I get time I will run php-cs-fixer fix --level=psr1 against the codebase to check we're at least PSR-1.

catch’s picture

Status: Postponed » Closed (cannot reproduce)
Issue tags: +Needs issue summary update

Looks like this is the right status.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.

quietone’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update