As linked to by Paul Jones there's an interesting whitepaper that's been published by Perforce Software about what they see as the Seven Pillars of Pretty Code.

The essence of pretty code is that one can infer much about the code's structure from a glance, without completely reading it. I call this "visual parsing": discerning the flow and relative importance of code from its shape. Engineering such code requires a certain amount of artifice to transform otherwise working code into working, readable code, making the extra step to leave visual cues for the user, not the compiler.

The goal of these recommendations isn't to help you structure your code better or to optimize it for the best performance. The goal is to make code that is easy to follow and simpler to read for both the experienced developers and those just coming in.

Their suggestions include making the code blend in, keeping the code "untangled", including plenty of comments and reducing clutter overall.

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.

On the SocialGeek blog there's a recent post that looks at making stubs for your URLs, making them easier to read and remember.

This is where the fun begins of course. How many times have you been confronted with someone sending you an indecipherable, thus untrustworthy link? Right, so we agree that for a user, it is important to have a clean URL that is readable and includes the title of the page or (at least) some description related to the content. Slug time!

They explain what slugs are (and how they're useful for users) as well as how to convert a title into a "slugged" string by replacing anything that's not an A-Z or 0-9 character to remove the less URL friendly characters.

On the PHP Security Log today, Stefan Esser points out some holes in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.

According to Stefan, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.

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.

The 'true hacker!' blog has a new post today that gives you a quick four step process for creating some clean, Digg-style URLs for your site with some simple Apache configuration changes (mod_rewrite).

You might have noticed that Digg has a cool way of maintaining clean URLs. Digg actually uses LAMP - Linux/Apache/MySQL/PHP. But where are the .php extensions? The answer is here. 4 steps to implement your own Digg style clean URLs.

His method turns on Apache's rewrite engine (you do have mod_rewrite enabled, don't you?) and adds a rule to push all of the requests to two default PHP files. There's also a ForceType method that can be used to achieve the same effect. One .htaccess file later, you're in business and the PHP script only needs to access the $_SERVER['REQUEST_URI'] value to get the parameters.

Bothered by the ugly way Xdebug stack traces were turing out, Derick Rethans has created a script to fix that.

I've always been annoyed by the way how Xdebug's stack traces looked liked. So I spend some time on making them look better. I will show the differences according to the following script.

The simple script takes the output and adds a bit of formatting, stripping down the information to make it a bit more clear. Check out the before and after shots to see the difference.

On his blog today, Ammar Ibrahim relays a story of how the Mail component from the eZ component frameowrk "saved the day" for a project he was working on.

A few days ago I was asked to develop a simple script for a solidarity campaign. The idea is that people send their photos as attachements to some email. The script would download all images attached and insert a record for that in the database.

I got introduced to eZ components during my last visit to Norway to attend the eZ systems conference. I decided to give it a shot, and oh boy it's just amazing, probably the cleanest and simplest API ever.

The Mail attachment provided all that he needed, and he includes the script (about 50 lines long) that he used to fetch the emails. He did have one issue with the ability to fetch a single email with the tool, but he managed to hack around it (script included as well).

If you've been programming for any length of time, you know the "joy" of working with someone else's code. When taking over a project, the first inclination I've seen with most programmers is to go in and format everything to what they'd like (or duplicate functionality). This is where the problem comes in, the trend that Michael Kimsal talks about in his new blog post - something he wonders about being an "antipattern".

I was discussing things with my brother the other day and I came up with a problem which he helped name. I'm currently maintaining some code, and it's quite a jumble. One of the things I can tell is that one of my predecessors began adding new sections of code to clean up the logic in other areas of the code. However, what never happened was the clean up of the old code, so now there's two places where the same set of data is retrieved in different ways.

He proposes the name "Multi Master Data" for the situation - two different sources, living in the same code, doing the same thing. Of course, he also mentions a situation where this type of problem can cause real issues, especially when trying to track down a bug (a bang your head on the desk moment).

On CodeSnipers.com today, Peter Harkins talks about a method, using regular expressions and Apache to turn ugly, GET-laden URLs in your application into clean, search engine friendly URLs without altering the underlying scripts.

So we have two goals. First, requests for the new URL are internally rewritten to call the existing scripts without users ever knowing they exist. Second, requests for the old URLs get a 301 redirect to the new URLs so that search engines and good bookmarks immediately switch to the new URLs.

He starts with a sample .htaccess file, showing a simple RewriteRule to take in the request and remap them back to the old PHP script's input format. They work through a few more changes, noting issues along the way (in case you hit them too) and end up with a simple, and much easier way to achieve clean URL bliss.