Love Fuel?    Donate

Thoughts, ideas, random notes, ramblings...

Anything about PHP in general, and FuelPHP in particular. Sometimes serious, sometimes with a big wink. But always with a message. Do you have an opinion about an article? Don't forget to comment!

After some internal discussion and already having adopted PSR-0 for 2.0 we have now decided to adopt PSR-1 as well. For the most part we were already following the recommendations put forward in there, but there is one big one: camelCase method names. We understand that many of you will have at the very least mixed feelings about this, we sympathize and share a lot of that feeling having used snake_casing ourselves for as long as we can remember.

Why?

One important reason is that we feel that more standardization among PHP projects is a good thing and should allow PHP to move beyond its current chaos. For that reason we adopted PSR-0 autoloading and Composer. Our biggest concern here is interoperability, third party code should easily and seamlessly integrate with FuelPHP. Keeping to snake_case because we like it better will have us miss the boat in the end. PHP itself has camelCased method names and snake_cased function names in the core, and that's probably as close as one could come to an official recommendation. Now with PSR-1 being close to a release we feel that the tipping point is reached.

Why not PSR-2?

Where PSR-0 and PSR-1 are a collection of recommendations that increase interoperability, PSR-2 is a complete coding style guide. We disagree with this coding style on 2 important points that will have no impact on interoperability. Instead of having the opening brackets on the same line we will use Allman style bracketing and we'll use tabs for indentation (instead of spaces). We will try to integrate PSR-2 as much as possible into our own style guide, but we will not fully adopt it.

Backwards Compatability

Clearly a change from snake_case to camelCase is going to mean making API-breaking changes which we are always careful about doing. In this instance we feel complying with an agreed standard is important enough to make this change, and thanks to our legacy package we will really strive to make this as smooth as possible. Basically the legacy package will alias old method names to the new ones, meaning you can update in your own time and not have to recode just to make the 1.x to 2.x switch.