For the past couple years, discussions about 'PSR-0', PHP standards, and some sort of framework standardizations have been popping up here and there. It wasn't until a bunch of 'PSR-0 Interoperability' patches started popping up in the Drupal core issue queues that I decided to take a closer look at PSR. (The latest? PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide) have been accepted).
There's a great FAQ that was just posted by Paul M. Jones explaining the PHP-FIG (PHP Frameworks Interoperability Group), which will give a little backstory to the group and its purpose. Drupal is a member of this group, with Crell (Larry Garfield) representing Drupal's vote for standards guidelines. You can see group members and discussions in the PHP Standards Working Group Google Group, and you can follow along with proposed and ratified group standards in the php-fig GitHub repository.
A lot of the larger PHP frameworks, CMSes and developer communities are represented, but—importantly—this group does not intend to represent PHP as a whole (that's probably the main reason it's now called the 'Framework Interoperability Group' instead of the 'PHP Standards Working Group'). Rather, it represents the mainstream PHP developer, and countless professional PHP developers working with and for the projects in the group. The main premise is that there are many large development groups working with PHP, and it would be helpful if these large groups could use a common set of coding standards, naming standards, and the like when developing their projects so things like the fruitful relationship between Symfony and Drupal can flourish (we're already seeing positive results here in the Drupal community!).
Drupal has already converted core subsystems to the PSR-0 standard for Drupal 8, and there is a PSR-0 compatible class loader in core.
Having set standards that many organizations follow (such as PSR-0, PSR-1, etc.) also helps unify PHP development and bring it to a higher level; many others have (often rightfully) criticized the PHP language and developers for being fragmented, inconsistent and amateurish. I'm going to adopt PSR standards in my own PHP side projects (heck, most of my code already conforms, so it's not a big deal to me), and I'm glad many organizations are working towards adopting the standards as well. It will let our community spend more time working on making better end results and useful classes than arguing over whitespace, bracket placement, and control structure formatting (to name a few things...).
There's another great article on Pádraic Brady's blog titled The Framework Interoperability Group (FIG): Openness, Accountability and Community Involvement in PHP Standards.
Comments
A few points:
It is good in that people using these standards elsewhere don't have to adapt to work with drupal.
It is a PITA for all the existing modules that conform to drupal.org coding standards to have to change, and if the module maintainer just goes and updates the whole module all the patches in the issue queue potentially break, and if it is done incrementally as new patches are committed then you end up with a frankenstein of different standards.
"It will let our community spend more time working on making better end results and useful classes than arguing over whitespace, bracket placement, and control structure formatting (to name a few things...)."
> This will never stop as long as there are people committing patches that aren't to whatever coding standards are being used.
We will always have patches submitted that don't conform, followed by someone asking them to clean it up, potentially followed by arguments back from the person who submitted the patch about how they don't want to for whatever reason.
Also, people who have been for ages being told they are doing it the wrong way and to do it this other way, will now be told again they way they were told to do it before was also wrong and now do it this other way.
That will piss some people off.
And these things are getting committed to drupal 8 but are they being backported (which increases the amount of PITA mentioned above)?
Or do we have to use different coding standards for different versions of drupal (which would also be a PITA)?
I'm not saying I don't like the new standards, I'm just saying this is a big change, shouldn't be made lightly and is likely to piss people off.
Drupal 8 is following the PSR-0 standard, which is only about class organization in the filesystem and using a different autoloader. This will have limited impact on most contrib modules unless your module has a tonne of classes.
There's been very little discussion about the PSR-1/PSR-2 coding standards within the Drupal community, and none of these will be adopted without discussion in the core issue queue first. I also would personally be opposed to any large changes in Drupal's coding standards since they're well established and applied to millions(?) of lines of code by now.
PSR-1 and PSR-2 have also only *just* been approved, so I wouldn't expect much to happen very soon. But I think that, over time, it may be possible to start adapting maybe just classes, then other libraries, to an updated standard.
Heck, Drupal's CSS coding standards were still in flux (barely even articulated) until just a few months ago. And there are hundreds (maybe thousands) of modules and themes that still don't conform to existing coding standards. I don't think it'd be too difficult to slowly migrate to an updated coding standard, especially since Drupal's standards are relatively close to the approved standards (with the exception of things like:
<?phpmethodName($argument)
{
// Notice the opening bracket on its own line, and the
// formatting of control structures, as well as the use
// of 4 spaces for indentation?
if (FALSE) {
// Do something.
} else {
// Do something else.
}
}
?>
I don't think the four spaces thing is as important or relevant (especially early on) as just popping the function/method braces onto their own lines. At least we're not using tabs :-)
I understand that it will piss people off, but I view this as an adapt or die type of thing. I'm not saying that coding standards will determine the success of the Drupal platform by any stretch of the imagination, but in the long run if Drupal can be more inviting to non-Drupal developers, the project will get an influx of new ideas and innovation which have been the backbone of it's success to date. Disruptive things tend to piss people off noi matter what, and in this case Drupal is on the other end of the disruption. I feel we should welcome change as opposed to resisting it, especially if it has mass adoption from the PHP community at large.
PSR-1 and PSR-2 cover slightly different things, by design, as a previous vote on a combined standard document failed in a vote.
PSR-1 covers, more or less, those coding standards that affect runtime behavior. That is things like not using short-tags, not having a closing PHP tag in an all-PHP file, etc. I actually think Drupal is already PSR-1 compliant, or could be tweaked to be so with very little effort. I think it would be valuable for Drupal to double-check that and if not, follow-suit. (There were some pieces of PSR-1 that I pushed to be included, in particular the stuff about side effects, specifically in response to some of the challenges Drupal is facing with some 3rd part libs we're considering for conclusion.)
PSR-2 covers those things that have no runtime impact, such as whitespacing rules. For the record, I voted No on PSR-2 as I don't believe it is of value, nor was it appropriate for the FIG group. Member projects are not required to adopt passed specifications, and I currently have no plans to propose that Drupal adopt PSR-2.
Looking through all the details of PSR-1, it looks like Drupal's coding standards already cover it. And for PSR-2 (which, I agree, isn't nearly as important at this time), we do most everything besides:
(Drupal does 2 spaces, PSR-2 does 4).
(Drupal does CAPS (e.g.
TRUE), PSR-2 does lower (e.g.true)).(Drupal has opening function/method bracket on same line, PSR-2 has it on next line by itself).
(Drupal has each structure on new line, PSR-2 has
} elseif {and} else {). (Same difference with 5.6, try/catch).Really, these are pretty small differences (besides the function/method opening brace), and even my OCD tendencies can survive with some files having four spaces, some two (it's not as bad as having tabs! :).
I think that it might be worth pursuing over time, but definitely not within a short timeframe (like Drupal 8 or 9).