PSR

PSR, a PHP Specification Request, is an attempt to standardise the way people use PHP in the hope that different sets of code libraries will work together.

There are some real problems to tackle. The different libraries and frameworks exist for a reason. Developers want different things. Here are some reasons for different approaches to building code libraries and frameworks. (Framed is a fictitious PHP based framework, not the Framed framework I developed.)

• Symfony, etc, are just too slow to execute. Use one of the modern frameworks.
• CodeIgniter, Symfony, etc, are too slow to develop. Use one of the simpler frameworks.
• I have some code and want to use it instead of learning other code so I will publish my code as a framework, and call it Framed, and use it on every new project.
• I have some code and want other people to see it and use it so here is FRAMED and I am going to remind you at every open source conference and spam every forum.
• I am comfortable using Framed and want everyone else to be compatible with Framed, instead of helping the developers change Framed.
• PEAR, etc, are too incompatible, even between their own modules. Use Framed.
• I want feature X and that is already in Framed.
• I do not need all the features of framework Y so I use Framed.
• I prefer the coding standards in Framed.
• I learnt Java in school and want a framework that looks like what I learnt in school.
• Companies pay more for people who know Framed. (They actually pay more for Java but some PHP frameworks are almost as complicated and difficult as Java.)
• I want a framework compatible with my existing system so I do not have to upgrade, I want compatibility with PHP 3. :-)
• I want a framework using absolutely the latest features of PHP so I can put it on my resume.
• If I can talk enough people into using Framed, I can release a professional version and charge money for it.

If PSR takes off and all the frameworks/libraries fit in with PSR, you can mix and match between the different libraries/frameworks, devaluing the individual frameworks/libraries to the point where nobody can charge for a profession version and focus development on a smaller number of popular libraries/frameworks. This makes life easier for Web site developers but also devalues their skills. This makes life easier for Web site owners and makes it more difficult for them to gain an edge over the competition.

PSR is design by committee, the opposite of the approach used by Google, Facebook, and many other organisations. If you have heard of Google or Facebook, you might want to reconsider the value of design by committee.

PSR has a rough plan along the lines of 1, 2, 3. To be PSR-2 compliant, you have to be PSR-1 compliant, and to be PSR-1 compliant, you have to be PSR-0 compliant, a further restriction on mix and match. The PSR-0 you have to comply with first is a real roadblock erected as a compromise between Symfony and Zend Framework, effectively limiting the current PSR market to those two frameworks.

Using PSR-0 as an example, PSR-0 is not semantic, it is not compatible across different systems, and almost everyone who looks at PSR-0 has a problem with the samples of code demonstrating PSR-0 because the code is politically correct, not compatible with the real world. Some aspects of PSR-0 make code interoperability worse, not better.

PSR, or PSR-0, is discussed in many forums with many similar suggestions for improvement but nothing happens. PSR-0 is rolling on to the point where is is set in concrete without anyone listing to any to the discussion.

Many people agree that an imperfect standard is better than no standard. The problem demonstrated by PSR-0 is that it is not a standard, there are no mechanisms to discuss, fix or evolve PSR. The problems with PSR-0 were known a long time ago, the solutions were highlighted at the time, but nothing changed. What are the chances of anyone fixing anything in the future? None! PSR is not a standard.

Imperfect standards can be fixed in code if the imperfection is something missed. In the PSR-0 suggestion case, the imperfections are specified as must do. You cannot just add in the missing bits in code because your improvements are illegal. You cannot raise PSR-0 up to the level of a standard because it outlaws some best practices and significant sane coding.

The code examples posted for the PSR-0 documentation, which appears to be missing, demonstrate a lack of experience with code development. There are many experienced developers ready to fix the code and, again, nothing happens. The incompatible ivory tower code is promoted as best practice and is already calcified below standard.

A serious problem today is the desperate rush of big corporations toward selecting everything based on check lists they downloaded from the Internet, without investigating anything on the list. PSR will creep onto those lists and you will have to be PSR compliant if you want to supply the companies with money. PSR will delay your development while you upgrade, or downgrade, your code to the PSR requirements. Your code will have less value because it will look the same as everything else on the market and people will just shop on price. In the open source world, a team in Mumbai can download your code, slightly change the spelling of a few names then sell their implementation of your code for one tenth of your minimum cost to deliver. The people in Mumbai may scream when they are undercut by the developers in Vietnam who used the same trick.

PSR-0

PSR-0 specifies autoloading the way a couple of the big frameworks do it. Most of the other conventions in those frameworks make interoperability, beyond class loading, extremely difficult, making PSR-0 almost useless. PSR-0 was put together by 20 representatives of legacy frameworks to make their frameworks work together to lock out new competitive frameworks. It is not a standard but they will promote it until people believe it is a standard.

PSR-1

PSR-1 defines some coding rules you MUST follow but is inconsistent and fails to follow the best practices defined back in 2000 when PHP 4 exploded into big time use. In simplest terms, PSR-1 is stuck in the last century.

PSR-1 is not semantic and actually bans all semantic approaches.

PSR-2

PSR-2 defines some coding styling rules you might want to follow if you are writing code for Symfony. You do not have to follow the rules because the only PSR rules you have to follow are in PSR-0 and PSR-1. If you do choose to follow the PSR-2 rules, about one in three rules will cause serious problems when you move from project to project. Some of the rules will prevent some publishers from using your code. The indenting rule will force you to stop using some device, screens, and software for viewing code.

Some items in PSR-2 are a step ahead of some items in existing coding rules, for instance the Drupal coding rules, but are still behind the best practices. Other items are an attempt to make PHP look like Java while others are just a step backwards for no apparent reason. Considering that well over 2,000,000 people develop with PHP, the PSR-2 rules from a committee of 20 people with vested interests in old code are not enticing.

Overall PSR-2 has no value because it is just a recommendation and is inconsistent. Some of the items are a step ahead of older school thinking so pick the bits you like best and leave the others until you are paid to change something.

Drupal code

Drupalistas will be flat out changing TRUE to true and uglyCase to UglyCase except, of course, where they are not allowed to use UglyCase or have to use UGLYCASE.

Update

PSR is steamrollering over everything else as framework developers scrabble to be compatible or die. CakePHP, SugarCRM, and others jumped on board. One noticeable change is the name of the group running the steamroller. It is now called the framework compatibility group to emphasise the fact that it is a move by some framework developers, not the PHP community.