The Most Important Conversation Ever

Posted: 2013-01-20
Category: PHP

The world today has a lot of hot topics that need to be discussed. Washington needs to get together to help sort out the debt-ceiling to stop the US economy going down the drain, but the Democrats and the Republicans just cannot even vaguely get the conversation going because they are happy to just oppose each other until the end of time.

Gun control is another hot topic, and I'm pretty sure the third-world is still struggling with debt and famine.

But no, that stuff doesn't come close to the important conversations happening in comment threads of blogs all over the PHP community. Let's discuss what "really" matters:

snake_case or camelCase?

Developers have been arguing about this since 1834 (or something) and it's not showing any signs of stopping. Most developers start off learning at home, and due to there being no consistent standard in PHP most people learned however the hell they wanted to learn. Their style preference often came from whatever framework, CMS, bullien board, etc they were using, and like me the first system I worked with was Postnuke, which was a fucking mess. Learning following that "style" meant I had no style, and when I eventually discovered CodeIgniter my code was much nicer at the time:

$this->db->order_by('foo')->get_where('bar', ['baz' => 1])->result();

While it might have looked better than the mess I was writing before, this code is just flagrantly ignoring the style of PHP's methods in the core, most likely because CodeIgniter was written before PHP had any classes in the core. There are now plenty:


Often I've heard developers say "PHP doesn't use camelCase for all its classes, what about MySQLi?". They sit there with a smug little grin on their face, ignoring the fact that MySQLi is an extension which needs to be enabled, but yeah ok it uses underscores:


But if we're talking about extensions there are plenty of others that do follow PHP's consistent naming conventions, three of which come to mind:


The learning towards camelCase is obvious to see. This, along with the fact that many large frameworks like Zend and Symfony also use camelCase, meant it should not have come as a surprise to anyone when the PHP-FIG voted and decided that PSR-1 was going to be camelCase.

I was a big snake_case fan for my methods and this was initially a turn-off to me, but do you know how long it took me to condition myself to like camelCase over snake_case?

A week.

Do you know I managed to achieve this amazing feat? I just used it, and after a week I didn't care anymore - because the difference is so damn trivial nobody should have cared in the first place.

So to my old snake_case brethren I have a message:

Using camelCase for your methods is consistent with PHP's core, with PHP's most modern and popular frameworks (including Laravel 4 which used to be snake_case but is switching to PSR-1) and testing utilities like PHPUnit. Trying to ignore camelCase and live in the modern world of PHP is going to be difficult, so you can complain or just suck it up and solider on - because either way it's already happened.

$some_var is fine, and some_func() is fine, but it's absolutely going to be $foo->someMethod() or your code is going to stick out like a sore thumb in any application that tries to use it, which is exactly why PSR-1 suggests the camelCase rule for methods.

If you're including code into an open-source application from 5 different sources then having 5 different coding styles for those methods would be painful. By everyone settling on camelCase we can use any code from anywhere and have consistency - which to a project like PyroCMS is important.

Tabs v Spaces

This is another big general argument, and seems to be the crux of peoples issues with PSR-2. They manage to completely ignore the positives of all the PSR's (even PSR-0 and PSR-1) and just complain about tabs being taken away from them.

There are a few points to be made here.

  1. You don't have to implement any PSR if you don't want to.
  2. You can simply implement PSR-1 if you don't like PSR-2.
  3. It doesn't matter.

From the reactions I've seen around the internet to people posting on various pro or anti PSR blogs I can just imagine developers sitting at their computers crying hitting the space bar over and over again until their thumbs bleed.

Well, I too was a tab guy, but then I ran PHP CS Fixer on a few projects and told Sublime Text 2 to use 4 spaces instead of a tab - and I haven't noticed the difference since.

So why does the PHP-FIG even care about style?

The most important thing to remember is that PSR's are really aimed at not only the projects that are part of the FIG, but for any code released by the FIG too. For example, PSR-3 (the logging interface) follows PSR-0, PSR-1 and PSR-2. It would be crazy if it didn't, right?

The FIG is going to be releasing some code over time to allow generic interfaces for common tasks, which means folks writing components don't have to write 10 adapters for HTTP interaction like PHP-Geocoder here. When the HTTP Client FIG is finished and Guzzle and Buzz have implemented it, the PHP Geocoder developer could simply check for "instanceof \PSR\HTTP\Client" instead of having to build out all those extra "adapter" classes. PSR-3 is the same idea but for logging.

This is what PSR-2 was made for. If you implement PSR-2 then wonderful, but if you don't then thats just fine too.


Anyway, me saying "suck it up" and accept camelCase as part of PSR-1 is all well and good, but why should you? Well, if you want your components to be received by any developer of any modern framework then using PSR-1 is a good idea and PSR-2 might not interest you - so don't use it if you don't want to.

If your company or open-source project has no style guide, then why not pick PSR-2 instead of picking PEAR or randomly inventing your own?

Fighting against an optional standard just because it clashes against your own personal preference is absolutely pointless. I say this for two reasons: the first is that the benefits of PSR-1 to its target audience massively outweigh any negatives that you can think up. Secondly, your (and my) personal preferences are not only pretty much irrelevant, but they are also malleable.

And please do remember, that camelCase for methods is in the core of the programming language, so trying to pretend they don't exist whilst continuing to develop PHP is like sticking your head in your sand. Commenting publicly about how much you hate camelCase is like sticking your head in the sand but standing next to a giant neon sign that says "LOOK, IM STICKING MY HEAD IN THE SAND!".

Let's grow up, stop shouting about what trivial preference we have about how we write the same damn code and build out a bunch of good quality consistent components that we can use in any framework, instead of rewriting things from scratch for the sake of moving brackets and underscores around.




Well said Phil, I'm sad that a post like this needs to be written, especially about such trivial parts of PSR.

Surely standards are a good thing for everyone even if they're not perfect or in line with everybody's personal taste.



...the end...



My personal preference concerning tabs doesn't matter to whom? It certainly matters to me. And it's not like no one gave any pragmatic arguments for their use. For one thing, tabs would allow everyone to KEEP to their personal preference while simultaneously adhering to the standard, something which is simply not possible with spaces without modifying the file.

Another common complaint against PSR-0 is that adhering to the standard has come to produce some inane directory structures like: Slim/vendor/slim/slim/Slim/Slim.php which can become very difficult to handle in an IDE's tree view, especially with frameworks with a more verbose naming scheme.

Rob Meijer


A lot of comments I've read are discussions about why one standard is better than another. Phil, you did a pretty good job of explaining the reasoning behind some of the decisions, but what people seem to miss is that none of these standards were decided upon unanimously. People voted, and a lot of people didn't get their way. Some of the standards that are defined are not necessarily the "best", or need to have a particular justification for existing, beyond that it's what won the vote.

Ultimately, having a single way of doing things is what matters, even if it's not YOUR way.






Just FYI on the history of the MySQLi API. Basically it was written outside of core as a contribution before there was the mandate to use camelCase for OO APIs and the author did not want to change it and there was nobody in core that wanted to make a big fuzz about it. Back then there were no RFCs so back then developers essentially just committed what they felt made sense and once something was in, well it was in. I guess at the time also nobody felt like just changing the API either, because that would have meant then likely having to maintain that entire chunk of code.

The result of all of this was however that camelCase was mandated for core OO APIs.

Kevin Wood-friend



I too was against camel case, coming from the CodeIgniter world. Switching to Laravel 4 and ONLY A DAY of using camel case, and I already enjoyed it more.



It seems like when PHP started out it was patterned after C and then a Java style influence crept in as PHP became more object oriented, causing the camel-case style to become more common.



Did you write the whole article? I'm pretty sure I have read the snake_case vs camelCase somewhere.



Magarac: Your tab preferences are irrelevant to other people, just like mine are. You can do whatever you like. The arguments have been had 100 times, and it's done entirely to avoid alignment issues. By using spaces for everything then alignment and indentation are both consistent. Thats fine, even though my personal preference is tabs on the left and spaces in the right.

I managed to ignore my personal preference, stop complaining and adopt a standard which makes my code consistent with hundreds of other developers. That's great for me but if you can't do that then just don't use PSR-2. Whats the problem?

As for those folder structures, have you ever looked at the folder structure or Gems? Madness. That said, that folder structure is not the cleanest I've ever seen, im used to looking at considerably nicer layouts like this:

Steve Wanless


This isn't about tabs vs spaces, it's about consistency. For what ever reason, FIG went with spaces and now those that choose to adopt PSR-2 will know that other PSR-2 compliant code will display consistently in a text editor.

If you have ever worked in a team then your going to understand the importance of consistency. Not every dev uses the same editor, but you all need to use the same tab/spaces setting so that others will be able to read your code.

This is all that FIG has done with PSR-2. I know I can open up Phil's open source code and have it uniform instead of a mess of indents.



I was using tabs 2 or 3 years ago too, I used my favourite CMS coding style and enjoyed it.
Then i became more and enthousiastic and decided to contribute on the core when possible leading me to work with people who don't have the same setting as me and github.

Committing from a windows machine, as long as i've used tabs, things were messy when asking for most pull requests and therefore properly rejected.
Then one day "someone" pointed to an article explaining simply that OS's don't share the same "tab" format for indentation while spaces where identical everywhere + every IDE, and even simple code editors (like notepad++) can automatically use space when pressing the tab button, with the setting of your choice.

Which mean that i can commit without breaking indentation, while not changing anything in how i actually code.

All of that to say, what's the matter with tabs Vs spaces ? Why is it even a topic ?

Shawn Mccool


When people learn a new language they gravitate to the code style standards and they don't think anything of it. They don't piss and moan. Instead, they fall in love with it or hate it based on their experience using the language itself.

The biggest problem with these sort of standards in PHP is that it hasn't had strongly supported and widely used standards such as this before. Consequently, every Tom, Dick and Harry who picked up PHP learned their own style (as mentioned in the article).

Consequently, there are now N standards where N represents the number of PHP developers. As a result, everyone represented by N-1 (the 1 being the people who have been using what would become PSR standards) is now forced into an awkward situation.

I'm not sure that people would be so passionate about this issue if they didn't at some intrinsic level value this type of standardization. However, we've become invested in our <tabs> or our snake_case and we have already specifically made the choice NOT to use the alternatives for a reason.

Now, we're being asked to suck it up and accept that maybe our reasoning wasn't correct?

The reality is that there are innumerable benefits from this standard. Pardon me for asserting this somewhat ridiculous statement but.. I feel that it's honest....

If every bit of code was standardized then mankind would have saved billions of <insert currency type here>.

Now, let's set that point aside and focus on less idealistic reasonings.

A popular argument against standards is that if it runs, if other people can understand the code, and if it's architected well then there's no reason to worry about code standards or code style.

I have 2 immediately responses to this idea. The first being that design-patterns are a set of standard approachs that were designed to deal with the fact that every programmer was solving problems in ways that could significantly be improved. It's hard to argue that studying these patterns improves your ability to engineer good software.

My second response to that argument is that I believe we've forgotten about middleware. Imagine that you have adopted the PSR standards as your own. Now, any time you wander into code that follows the standards you feel perfectly at home. Whenever you inherit some mosterous legacy chunk of code.. you can just throw it into the PHP Coding Standards Fixer and suddenly.. you're converting terrible code into "mostly" your own personal style.

It's much easier to write middleware that targets styles. Ask anyone who has had to write code that could parse data out of any number of code styles.

Finally, I honestly just don't believe that my personal style matters anymore. Yes, I was sort of bitchy about camelCase at first despite having used it consistently for MANY years. This was because I liked how Ruby code looked etc (I had almost at one point in time left PHP altogether).

This debate is getting to be sort of ridiculous. We're not particularly good programmers. Maybe you are, but you're probably not. We're just people who have jobs and make products and try to be as professional as possible. We strive always to become better at what we do and I see this as an opportunity to do so.

Does using PSR standards and style mean that I'm a better programmer than I was before? No, probably not. However, I believe that having made the choice to throw away my personal preferences in order to adapt to a standard DOES make me a better programmer now than I was before.

I challenge everyone to just switch to PSR-2 for a couple of projects, front to back. I think that you'll realize --as I did-- that it just doesn't matter.

Posting comments after three months has been disabled.