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

Emran Hasan has a quick new post to his blog today looking at how you can change the default controller naming scheme that the CodeIgniter framework uses (to prevent things like naming conflicts and the like).

CodeIgniter is one of my favorite framework and I often use it for developing application quickly. Although it is very flexible in most cases, I find its naming convention to be strict. Many times I have faced this problem when my controller's class name and a model/library's class names are the same '" a Fatal error is inevitable.

His method involves extending the core CI_Router class to change the _validate_request method to change the location and the naming convention (from Users to UsersController) for the default controller settings. Code for the update is included.

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.

Nathan Good has posted five tips PHP developers should use in their work to develop good programming habits to the IBM developerWorks site today.

Just like any language, developers can write code in PHP that ranges in quality from truly awful to very good. Learn good programming habits that can help you bridge the productivity gap. [...] Bad coding habits seem to accompany defects in code and can cause code to be difficult to change without introducing new defects. The following five good habits, when applied to your PHP code, will help you avoid these pitfalls.

Here's the list:

• Use good naming.
• Take smaller bites.
• Document your code.
• Handle error conditions.
• Never, ever, copy and paste.

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.

A new entry has been posted to the PEAR blog with the latest minutes for the group's July 13th meeting.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

With more recent talk about namespaces in PHP 5.3, bloggers all over are tossing their comments into the discussion. Chris Hartjes is one of the latest with his thoughts on the point of the functionality.

I'm an outsider when it comes to tracking the going-on in the world of PHP internals. So, because of that, I'm not going to comment on the actual syntax of how namespaces will be implemented or it's impact on internals. That's not really important as far as this particular discussion goes.

He mentions one of the primary arguments for namespaces from the casual developer's perspective - keeping things separate and so classes can have the same naming as some of their cousins in other namespaces.

Tobias Schlitt has posted some comments on things recently said on PHP's upcoming support for namespaces - specifically on the ideas about naming classes the could conflict with PHP's own internal ones.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don't use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.