Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. In this session you will learn how you can offset your technical debt with clean code that is readable and testable as well as reusable.

You can listen to this latest session either using the in-page player or by downloading the mp3 directly. The slides (for a similar version of the presentation) can be found on Slideshare.

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

After seven release candidates, it's clear PHP 5.4 is coming: as always the improvements from the previous minor version are many. [...] Let's look at the new features and score them on two metrics: usefulness, and potential for abuse. I'll try to avoid discussing non-language related matters.

He starts by pointing out some of the "gotchas" that can happen with traits (like errors thrown when more than one method is named the same and that they are a separate hierarchy), the short syntax and dereferencing support for arrays, closure binding, upload progress and more. For each of them he gives two measurements - the usefulness of the feature and the potential for abuse.

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.

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.

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.

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.

]]> Wed, 04 Apr 2007 07:15:50 -0500 http://www.phpdeveloper.org/news/6842 http://www.phpdeveloper.org/news/6842 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.

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.

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.