When is a Standard Bad for a Standards Body?
tl;dr: FIG is a welcomed force in PHP standardization. But I believe their recent two standards have undercut their credibility. By choosing contentious grounds, issuing an arbitrary standard that competes with existing conventions, and doing this in an area that does not actually improve the interoperability of code, they have weakened their position as a standards body. I suggest that they remedy by downgrading PSR-1/2 from "standard" to "recommendation."
In mid-June, the relatively young Framework Interoperability Group (FIG) proposed a pair of new standards called PSR-1 and PSR-2. FIG's ostensible mission is to provide PHP-related standards to bring some level of interoperability between the plethora of PHP frameworks and applications.
But these two standards, and PSR-2 in particular, have in my mind undercut the larger goal of the standards body. That is, releasing these two documents as formal standards harms the credibility of what had looked like a very promising standards body. Here I explain why I think this, and suggest a remedy. <!--break-->
In Praise of PSR-0
FIG's first standard was called PSR-0, and it was a much-needed standard, a breath of fresh air.
The developers of the PHP language itself have taken what might be considered a laissez-faire attitude toward the way PHP is used. For many common cases (tasks like reading a file off of the file system), there are many ways of doing essentially the same task, and yet PHP itself does not dictate which is preferred, which is best.
In many cases this is a boon. Projects can choose the method best suited for the task or for the community. But sometimes this "openness" substantially harms interoperability. The growth of truly independent libraries in PHP has been hampered in no small part because of the fact that "everyone does it their own way".
Here is a case in point: Loading PHP files. For many years, one needed to manually include all of the files one wanted to use. There was no standard way of mapping, say, a class to a file name. When PHP introduced an autoloader -- a feature allowing developers to map classes to files in user-space code -- the various PHP projects still implemented autoloaders in grossly divergent ways. To use two different libraries, one might have to register (or write) two different autoloaders. This was cumbersome both on the developer and they system.
Along came FIG with a solution. The PSR-0 standard defined a convention for mapping class names to file names, and then provided a reference autoloader.
This changed the PHP culture. Large frameworks jumped on the bandwagon, and projects like Composer provided unification in the dependency management layer. PHP, long in the rears on the basics of library management, suddenly closed the gap with the likes of Java, Python, Perl, and Ruby.
PSR-0 may have saved PHP.
Why is PSR-0 So Successful?
PSR-0's success is easy to explain: It meets an acute technical need. It makes the programmer's life easier, and it is a needed first step toward actual program-level interoperability.
Just a week ago, I used components from three different frameworks to build an application. And it was trivially easy because all of them supported PSR-0. Frankly, I never read the code to these libraries -- I just used the public APIs according to the documentation. Two years ago I would have spent more hours just loading all of the right stuff than I did building the entire application. I would have had to dive into the code of each project just to figure out what I needed to load and when.
FIG was successful with PSR-0 because they introduced a standard that made sense, that helped solve a technical problem, and that made the average programmer's life easier.
Along Came a Spider
Then came PSR-1 and PSR-2. These two standards -- they are called standards, not recommendations or conventions -- dictate coding style.
PSR-1 is reportedly a "basic" set of coding conventions, standardizing practices like capitalization of class names and general layout of a class file. In many ways, it's not dissimilar from what many programming languages have introduced in their basic documentation.
PSR-2 is the detailed coding standard, covering everything from where every parenthesis and curly brace ought to go, to how many spaces and indent should have, and to how long each line of code may go (120 columns!).
First let me state one thing emphatically: I am all in favor of coding conventions. I have seen some code formatting atrocities that would make Jackson Pollock vomit. And on the converse, I have witnessed how convenient it is when all of the code is visually the same. Coding styles are convenient, though clearly not necessary.
But I think FIG made a gross misstep in dictating a standard.
A Good Standard
Each standards group has a purpose. W3 seeks to build standards for the web. Java and Python have standards groups who churn out standard interfaces and processes, and even develop the features of the next generation of the language.
And FIG's purpose is to promote framework interoperability.
PSR-0 is a great example of how to increase interoperability, for it makes disparate standards-compliant libraries work together better.
But do coding conventions increase interoperability? No. In fact, they have almost no impact on interoperability. The language itself enforces the essential syntax constraints. If it runs in a PHP interpreter, it doesn't matter how many spaces one indented nor whether or not there was whitespace between the namespace declaration and the class declaration. And when I use two libraries, the spacing around an = operator makes absolutely no difference in how the libraries function in tandem.
But isn't it nice to have all the code formatted the same way? Yes, it is. It is convenient. But this is the happy tip of a malevolent iceberg.
Rational Disagreement
How many characters should be used to indent in code? 2? 4? 8? And should tabs be allowed? Required? Everyone has their opinions, and for the most part these opinions are rational. There isn't necessarily a right answer.
How about this: should there be a space between if and the opening parenthesis? Again, there is room for rational disagreement.
But in both of these cases, people assiduously draw their lines. They have their preferences, and they stick to them. And there are already several popular coding conventions for PHP.
Now enter the new standards body, FIG.
A Rock and a Hard Place
FIG simply dove into the fray and chose to dictate standards to a wide variety of already developed applications. PSR-1/2 were derived from a survey of 20 or so PHP projects, but the FIG standard doesn't necessarily match any of the existing coding standards (though it comes close to Symfony's). This means the standard begins by demanding that all of these projects change, but with no subsequent technological improvement. Inertia is already against PSR-1/2.
By claiming that these are standards, they have also placed equal importance on PSR-1/2 as they did on PSR-0.
What they have unintentionally done is undermined their position on two fronts:
- By dictating that coding conventions are on equal level with their other standards, they have matched the crucial (real, problem-solving standards) with the superficial (consistent-looking code).
- By taking a hard line on an area of broad rational disagreement, they have intentionally positioned themselves in the midst of a controversy, while simultaneously not offering any justification for taking PSR-1/2's standard over any of the myriad competing standards.
Combined, these two have an unfortunate result: Developers will dismiss PSR-1/2 -- especially PSR-2 -- as overzealous and optional, and this will change people's perception of the standards group.
This will most certainly impact FIGs future standards efforts, where developers will take their suggestions less seriously, and immediately view proposals with a jaundiced eye: "is this arbitrary lawmaking or real innovation?"
What FIG Could Have Done (and Still Should Do)
A group dedicated toward real interoperability should have stayed away from dictating superficial trappings. They should avoid, at all cost, diluting the power of well-reasoned problem-solving technical standards with arbitrary conventions -- especially when their doing so is competing with other more established conventions.
They could have made recommendations or conventions for coding style -- in fact, I still think they ought to. PSR-1/2 is still valuable, but as a recommendation of obviously lesser importance than PSR-0. But they should absolutely not call it a standard.
Moreover, FIG's biggest boon is in filling a much-felt gap in PHP: The fact that interoperability is damaged by technically incompatible (or, more properly, compatibility-agnostic) solutions.
I, for one, would love to see Composer-style package declarations become standardized. I'd like to see a reasonable namespace convention, too, since that aids toolchain, programmer, and runtime alike. And I'd definitely welcome some interfaces for oft-implemented patterns. In short, I'd like to see standards that improve the actual interoperability of PHP libraries and frameworks, and that do so in a clearly reasoned manner.
Other standards bodies manage this well. They must. Their survival depends on it. FIG's does, too.
Update: Engineered Web also has a blog post on PSR-2 that takes a novel approach: PHP coders rarely work in a vacuum. We work with other languages like JavaScript. Shouldn't the PHP coding standard be influenced by the standards of those other languages?
*Updated: * Corrected one instance of SPR to PSR. Thx @DamienMcKenna.
