PHP Coding Standards

Fri, May 25, 2012 07:27 PM
Update: Matthew Weier O'Phinney, one of the core members of the group, has cleared up the naming history in the comments.

During the /dev/hell podcast at Tek12, someone asked the guys their opinion about PSR. I did not know what PSR was by that name. A quick search lead me to the Google Group named PHP Standards Working Group. I had vaguely remembered a consortium of frameworks, libraries and applications that were organizing to attempt to make their projects cooperate better. But, this did not sound like the same project. Another search and I found the PHP Framework Interoperability Group on Github. A bit more searching led me to a post where apparently the PHP FIG changed their name at some point citing people not knowing what FIG meant. But, this is not a history post. The group had done some work on setting a standard for auto loaders in PHP. This is a very good thing and much needed. That is a real thing that impacts real developers.

The person asking the question had asked about PSR1 and PSR2. These are the first two standards proposals in the group and they deal with coding standards. There were mixed feelings in the room about the proposals. I asked (being me, probably with very little tact) why in 2012 were a group of really smart people still discussing coding standards such as tabs vs. spaces. Because this is what immediately came to mind for me.


There are already coding standards for PHP and any other language out there. Why does anyone need to make a new one? For Phorum we chose the PEAR standard (ok, with 2 minor modifications). On top of that, every one of the projects in this group already have coding standards. Why not just pick one of those? Are 10 projects that currently have their own standards going to actually all change to something else? I highly doubt it. My guess is that, at best, they will all end up with a modified version of the groups standards.

This reminds me a lot of Open Source licenses. There are tons of these things. And in the end, most (GPL has its issues I know) of the open source licenses represent the same idea. I suppose you could say that most of all of them fall into GPL like or BSD like. Anyhow, I quit worrying about having my own license years ago. I now just use a BSD style license that you can generate with several online BSD license generators.

When I voiced my concern about what is, in my opinion, a waste of very smart people's time, my good friend Cal Evans (He has bled in my car. So, I think he is my friend. And I hope he feels the same.) said that I was misunderstanding the point of the group. It was a group of projects that were collaborating to try and use similar standards and practices to make the PHP OSS community better. And that is exactly what I thought PHP FIG was. However, the group name is now "PHP Standards Working Group". That reminds me of the W3C HTML Working Group. And in my mind that means a group that is deciding the future of a technology. In addition the proposal being discussed is titled "PSR-1, a standard coding convention for PHP". If you pair that with the name of the group, it sounds very authoritative. And I don't think that is by accident. If I was heading up such an effort, I would hope that every PHP developer on the planet would follow it too. If you saw Terry Chay's keynote at the PHP Community Conference last year, he talked about frameworks and platforms. He pointed out that the reason people like Facebook were sharing their data center technology was in hopes that people would start using it and it would become common. Thus meaning the equipment they are custom building would be cheaper and people they hire would already be familiar with it. But, if the point of the group is *only* cooperation between lage OSS PHP projects, I wish they would pick a name that is more indicative of that. As it stands, when I landed on the page, my immediate assumption was that this groups intention was to dictate to the rest of the PHP world how to write their PHP code.

In the end, cooperation is good. And if these guys want to cooperate I say more power to them. I just hope they get into really good things soon. Like, can we talk about a maximum number of files, functions or classes used for any one single page execution? *That* would be valuable to the PHP community. I can deal with funny formatting. I can't deal with poorly performing code that his dragged down in abstracton and extension. Or how about things like *never* running queries inside loops that are reading results from another query. That would be a great thing to make examples of and show people the best practices. Tabs vs. spaces? That should have been solved 10 years ago. When in doubt, PHP code should do what the PHP core does. This is PHP we are talking about. Would it not make sense to have the people who write PHP writing code that is somewhat similar in style to those that make PHP? C and PHP syntax are very, very similar. So, why don't we all just refer to the PHP CODING_STANDARDS file when in doubt and not even worry with the little stuff that does not affect performance?

So, as of a few minutes ago, I have joined the group. If for no other reason, just to see what is discussed. Perhaps I should follow the advice I give people when they ask for features in my projects and do something about my issues and worries.
Gravatar for Justin Rovang

Justin Rovang Says:

Spot on, on the moonspot :)

I completely agree over the naming implications as well and the comic is perfect.

I think there needs to be guidance on standards - e.g.: a list if high quality standards, and why they're important. But not on an authoritative sounding level, just as you mention.

The survey data guiding the PSR-2 detailed standard is a bit poor - most notably: 'method names', only 1 vote for lower_under? Hmm, with sample sets of roughly 22 per category, I'm certainly not sold on what the common denominator is...

Gravatar for Robbo

Robbo Says:

PSR-1 I have no real issue with. PSR-2 seems inconsistent and in general is against how I have coded with every project (including OSS I extend).

Honestly though. The only useful thing out of this is the autoloader. Although most people should have been doing it this way already.

If I open a file that is coded in a different style I use that style. Unless it is terrible or messy it really isn't hard to adapt to different new lines, spaces/tabs or naming schemes.

Gravatar for Jordi Boggiano

Jordi Boggiano Says:

I think you are missing the point. It's not just about frameworks, it's about all the little libraries out there. Each adopting various coding standards (or worse, creating their own). The problem is that saying "let's use PEAR" won't fly, because person A doesn't like PEAR and doesn't want anything to do with it, another one will not want to stamp his project with the Symfony name, etc. The community is fragmented, and that creates tons of problems. Also as you say you adopted PEAR +/- those littles rules. I think that's lame. It means if I know the PEAR CS I can't just contribute to your project, I have to mind those two exceptions you made.

Now what I hope PSR2 will achieve, much like PSR0 did to some extent, is that it will be a white label CS everyone can use without fear that they are giving in to this or that community by using their CS. Everyone can just use the same, because it's been made in a demilitarized zone of sorts. It is neutral. And if you take it and make a few exceptions to it, you're again missing the point. CS should not be about taste, if we all used the same, we'd all agree it looks better. I have been using variations of every rule over the years and at every point in time I have been firmly convinced the other ways of doing it sucked. Point is, it doesn't matter, it's just habits. So let's settle for the same habits and be done with the silly discussions already.

Gravatar for Petah

Petah Says:

What I dislike about the PSR standards is that they only roughly define how to name object properties. But then, even worse, they don't at all define how these should be reflected into a database schema.

So if we are to do lower_under, then should we also do lower_under in the DB? Or do we mix camelCase in the PHP side and lower_under on the DB?

I would love for there to be a standard, even if every one does not stick to it, there is at least that definitive standard.

Personally I dislike the open braces on a new line, and I use camelCase on the PHP side, and lower_under in the DB, but that's just me.

Also a limit on application complexity ("maximum number of files, functions or classes") is ridiculous. As long as the code base is not terribly designed, then you can always throw more hardware at it if you need too. The important part is code maintainability.

Gravatar for Matthew Weier O'Phinney

Matthew Weier O'Phinney Says:

I need to clarify a few points. The original name of the group was the PHP Standards working group, and that's the name the google group was started under. However, it quickly became clear that the name was turning many people away, and really didn't describe the group or our intentions - which were to find common ground between frameworks and libraries, and make if easier for folks to mix and match between them. Originally, PEAR had largely served in this role, but a lot of people had negative reactions to that organization (though I've never understood why). Fabien and I discussed this a couple years back, and felt the name PHP Framework Interoperability Group was a better fit, and alao gave us another easy to remember fruit acronym (figs are tasty!). It was at that time we created the github repo.

While coding standards aren't sexy, they are still important for interop. If you're mixing libraries, you often mix up with a hodge-podge of coding styles - class and method naming conventions differ enough that it becomes easy to make mistakes when mixing objects within the same scope. Additionally, if you start debugging, it becomes jarring going from one context to the next. Having a common standard can make the lives of those developers consuming libraries easier.

Do I hope the group will tackle other standards? Yes. But I wouldn't call what has been done so far trivial or pointless; I would call it a good foundation.

Gravatar for Brian Moon

Brian Moon Says:

I really appreciate guys from the group posting here. Thank you for your input and clarifications.

@jordi "The problem is that saying "let's use PEAR" won't fly, because person A doesn't like PEAR and doesn't want anything to do with it"

I would say, see the comic in this instance. That is all that is happening here.

@matthew Thanks for the naming clarification. Sorry I got it backwards.

Gravatar for Brian Moon

Brian Moon Says:


"then you can always throw more hardware at it if you need too. The important part is code maintainability."

This is the exact opposite of what many, many people told me this week at tek12. Most people have some hardware and that is all they have until budgets are approved 1 or 2 years from now. Also, I am not sure why the two have to be in opposition. Although, I will say, I find a code path that includes 20 classes in 15 files to serve one page to be NOT maintainable.

Gravatar for Till

Till Says:

@Brian: Do you mean maintainable (in terms of development) or scalable (in terms of hardware)?

IMHO, coding standards allow scaling the team better. Code follows convention and as long as people follow it, it is easier for a developer to dive into a code-base. These standards don't help with technical depth, etc. – after all you can still build a lot of 'crap' on top of these standards but they still manage people to get around easier.

Gravatar for Brian Moon

Brian Moon Says:

@Till, standards are very important for maintainability. My point is that we don't need a new one. There are plenty out there to choose from just like OSS licenses.

There is no reason you can't have maintainable code that performs. But, comments like @petah show that many, many people don't consider it all when developing their code instead opting for some glamorous abstracted mess.

Gravatar for Hari K T

Hari K T Says:

Hi Brian Moon,
Your comic is correct . We will be adding one more standard.
But the fact is all other standards will be dissolved soon. So finally we will be having one standard.
I don't know the reason why people are too much concerned about tabs and spaces. In every editor you can set 1 tab = How much space you want to keep. Looking through the github codes you can see the beauty of codes with spaces and tabs mixed :-) .

PSR-1 and PSR-2 are awesome . Change is the rule of Life . So we need change ... May be at a later point we need to change PSR-1 and PSR-2 to some other names. But now this is fine :-) .

Thank you

Gravatar for EllisGL

EllisGL Says:

I like the open brace on the new line, what I don't like is that they change the definition of where braces go on IF statements.

Also the "<?=" thing should be killed in my opinion, since it's read to me "question mark equals 'whatever'". If they are dropping the short open tag, just drop it all.

I guess these two things so how they will still have multiple "standards" for different cases, when the could simplify the whole things to "braces are on new lines, nothing after the braces and no short tags what-so-ever".

Gravatar for EllisGL

EllisGL Says:

Also, I do like they made it standard for a 4 space indention. No more editor display issues that way. =)

Gravatar for Till

Till Says:

@Brian: Yeah, I agree – after all the psr-X standards are heavily modeled after PEAR's coding standard. If relaxing PEAR's coding standard a little and changing the name helps adoption because people have some sort of PEAR-phobia, then I guess I am for it. :)

I was hoping more contributions would also go into PHP_CodeSniffer, but so far NIH persists and certain people rather role their own. :)

Gravatar for Cal Evans

Cal Evans Says:

Hi Brian!

I've bled in your car, you've drank at my house; yes we are good friends. :) Matthew said it best, FIG is a much better name for the group. I'm pretty sure we discussed the name in the episode of @elephpant that we talked about this group,


Gravatar for Lukas

Lukas Says:

Its not about creating another standard since the +1 votes came from real projects that are now starting to adopt this standard in place or as an extension of their current standards. As such this effort is resulting in fewer different standards (and fewer projects labeling the same standards with [My project name] CS) by some of the leading PHP projects.

Gravatar for Kyle

Kyle Says:

@Hari K T

"But the fact is all other standards will be dissolved soon. So finally we will be having one standard."

I think that's idealism. If articles like this are any indication, not everyone is going to adopt the new PSRs. I understand that's the intention, but it just won't happen that way.

For instance, my company has already adopted our own coding standard. If we decide to release a piece of code as open source, most likely we aren't going to change the formatting just for that (depending on how big the package is). We will release the code the way it is currently formatted.

If only because of the fact that legacy code exists and will be released, we should understand that one standard to rule them all is idealistic, but not realistic.

I support FIG, and thought PSR-0 was an important step towards framework and library interoperability. I also appreciate the significance of code formatting for debugging, and for authoring all the same. But the idea that other standards will fade is incorrect, imo. PSR-1/2 might become the majority, but there will always be libraries and frameworks that don't conform.

This type of approach is just as likely to create a second (and third and forth) standards group, as it is to create a single standard, IMO.

Gravatar for Justin Rovang

Justin Rovang Says:

I can't quite put my finger on it, but it feels as though a little freedom is being ripped from the innovators who write code not dictate a community.

I get the kumbaya feeling from a universal standard... but I still feel like PSR2 is more
About dictating than guidance.

Kind of like currency... look at the euro right now ;)

Add A Comment

Your Name:

Your Email:

Your URL:

Your Comment: