They initially started out as one proposal but the initial round of voting didn't yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.

I went for Interview and there interviewer asked me few questions. I disagreed on two questions and their answers. [...] After I disagreed [about parentheses being required on class creation] they said it is essential in new PHP version 5.2.x. Still I disagreed then he said, no no after PHP 5.2.x, PHP is like Java. [...] I like PHP and I do not want it to become Java. If just by implementing Object Oriented Programming PHP can become Java then I will say Java is C++ or Java copied C++.

He proves his stance with a bit of sample code showing that the object creation doesn't require the parentheses to create.

Especially when first getting started with various web development languages, it can prove to be a difficult task to learn all of the various naming conventions from language to language. This can be even more confusing when developers disagree on what's considered best practice. To help ease the transition for beginners, this list will describe some of the more common conventions.

Some of the conventions that they mention that are more specific to PHP developers are underscores before property names, uppercase constants, capitalized first letters in variables and alternative syntax (like ternary).

I think the underscore-prefix for protected and private is a good convention to keep. As with many things about programming, this convention is not for the program, it is for for the programmer. For example, limiting your line length to about 80 characters is a good idea, not for reasons of "tradition", but because of cognitive limitations of human beings who have to read code. Likewise, using the underscore prefix is an immediate and continuous reminder that some portions of the code are not public. Its purpose is as an aid to the programmer.

He suggests that it offers something similar to the thought process behind the magic methods like __get or __set that both work on a private scope. Check some of the comments for opinions both for and against the idea from other community members.

Usability guidelines can sometimes be of use in awkward places. I try to apply them to source code. [...] Of course, coding guidelines are there to make the code easy to read by everyone. But code usability goes somehow beyond. Let's see some of the differences.

He compares good versus bad code in a few different areas:

• Bad Code Comments
• Split Up Code
• Cleanliness
• New Conventions
• Listen To User Feedback

Each item is described, some including code examples to help make them more clear. Be sure to check out the comments for more good suggestions.

I've had the pleasure of maintaining a legacy application developed by people who were past deadline the second they had their assignment handed to them in the past and it can get really interesting rather quickly when you see how sloppy you can get when you are in such a hurry. Here are some guidelines I've given myself to ensure that the structure is correct at the end of the day.

Some of his suggestions include:

• Breaking larger files apart into smaller, easier to maintain pieces
• Correctly naming functions/variables/etc
• Tabbing/spacing in to indent code blocks
• Input validation and error checking should always be included

In my regular web wanderings recently, I found a great post entitled "The 7 Worst Verbs Programmers Use In Function Calls" and couldn't help but be reminded of a system that I worked on a few years ago. The core function of the system was named - no kidding - "doStuff". Everything in the application led towards that, used it, and then did other things as a result.

He suggests a structure he uses - "verbAjectiveNounStructure". Starting with an action, moving to a description of the action, to the target of the action and finally an optional structure - how the returned data is formatted.

By default now, Cake will automatically use the AppModel class and create a unique alias to a database table if it does not find the file. This means that if you have a table that follows the Cake conventions, needs no validation, and has no associations to other tables, you don't even have to create the model file any more. Woah, talk about a serious time saver in some cases.

He also mentions a gotcha to keep an eye out for - misspelling the model name when you use it. It'll definitely break things. You can find out more about models in CakePHP from this section in their manual, The Cookbook.

We've been together for about five years now. I've had a lot of good times and I've really enjoyed being with you. However, the more we work together, the more concerned I get about our future. I'm sorry, but you don't have the elegance that inspires me to want marry you. I think it's time we broke up.

Some of the reasons given for moving on is PHP's seeming identity crisis, consistency in function names/functionality, and performance issues that were just too much.

Despite being a bit anti-PHP, it's still a well-written piece. Check it out...

The ogo project aims to clean up PHP, starting with fixing the inconsistent (and difficult to remember) function names. PHP needs clear naming conventions, and it needs to stick to them. We will offer a temporary fork until function name changes are agreed on, and sensible backwards and forwards compatibility is in place. Then we can get our changes merged into the main branch.

They've already posted some suggestions for a few things, including conventions they're looking to follow and a list of new function names changed according to these new conventions. There's also a downloads and forum section that will soon have content.

If you're interested in getting involved, stop by the #ogoproject channel on the Freenode IRC network and see what's going on.