On Reddit.com there's a heated discussion going on in response to this bug filed asking about aliasing PHP function names to make them more consistent (specifically "htmlentities_decode" versus "html_entity_decode").

[...] Current naming conventions are really horrible. For instance, look at differences between str_replace, strlen, parse_str, htmlspecialchars. All work with same type but their names are completely different. So, string functions should go to String namespace (Stringreplace()), array functions to Array namespace (Arraysearch()) and so on.

Back in the Reddit post most of the commentors agree that this kind of thing would be beneficial to the language, but - as several point out - this could have serious backwards compatibility issues. What do you think? Voice your opinion!

Rafael Dohms has posted a new review of a book that focuses on helping you create better, more readable code - "The Art of Readable Code" (Dustin Boswell, Trevor Foucher, O'Reilly). This is isn't about "pretty code" as much as it is manageable, easy to follow structures and logic flows.

"The Art of Readable Code" was written by Dustin Bowell and Trevor Foucher and basically focuses on concepts and suggestions to make you code not just readable, but comprehendible by other developers, or as the author's suggest, yourself in six months. Code readability is a topic that I truly believe the PHP community does not focus enough on and i really wanted a look at this book to see what kind of ideas it had and what I could do my best to bring to the attention of other developers.

The book is language-agnostic and provides ideas that developers should keep in mind when doing their development - clear variable names, making comments that make sense, refactoring tips and hints for implementing your ideas in code. He recommends the book to any developer (in any language) to help them make code that will stand the test of time and be easier to manage/understand in the future.

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.