On the Web Scripting Blog today, Satya Prakash has a reminder for developers and those hiring them alike - PHP is not Java.

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.

On NETTUTS.com there's a new article that list nine different conventions that developers (PHP, Javascript, general web) could get confused about when they are just starting out.

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).

In response to a post from Leszek Stachowski about underscores in PHP class development, Paul Jones has shared his own thoughts on the matter - that he disagrees with Leszek and suggests keeping the underscore prefix for private methods.

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.

Francois Zaninotto has a recent post looking at something every developer should consider when creating their applications - especially the libraries that might be used by other developers: code usability.

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.

Shawn Straton has posted the second part of his look at code readability today. This time the focus is on the structure of the code - file structure, code layout, etc.

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 a new post to his blog Keith Casey shares a few tips on naming conventions that can help increase readability in your code and make maintenance simpler in the future.

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.

In this new post to his blog Chris Hartjes mentions a "nifty little feature" that the latest version of the CakePHP framework has - dynamic models.

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.

As anyone that's worked with a programming language for a long time knows, you get to know the ins and outs of it pretty well. You get a good feel for how it all works and how feel confident in your skills with it. But what happens if you decide to move on and leave the relationship? Check out this take on just such a situation from the Yet Another Web Development Blog.

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...

There are some PHP developers out there that see PHP as a sort of constant "work in progress" with issues all around - confusing function names, non-intuitive features, and more. So, a group has been formed to help clean things up a bit - the ogoproject.

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.

Keeping with convention - well, naming convention - is a good thing sometimes. Demian Turner thinks so and talks about one of many reasons he sees to follow a standard set in place for a while now - the PEAR naming standard.

By far the most convincing reason to use the file naming convention, which means that a class located in your include path like Foo/Bar/Baz.php is called Foo_Bar_Baz, is the ability to take advantage of PHP 5's __autoload magic method.

The __autoload functionality in PHP 5 is definitely one of the most handy, elegant single lines of code out there and I'd definitely vote for anything that will make working with it even easier. Demian also includes a few lines of example code to show the interaction between the function and the files with the naming convention.