Continuing on from a previous post, the PHP in Action blog takes another look at their suggestions on "beautiful code" with some responses to the previous post.

I got some interesting comments to my previous post on "beautiful code". Some were pretty strong disagreements. So am I wrong? Did I get carried away? Did my critical faculty go on vacation somewhere nice and sunny? [...] My main point is that it's close to plain English. Not everyone agrees that that's a good thing, but I argue that we're built (genetically wired, in fact) to understand natural languages, not program code.

He reasons that code should be easier to understand than just a bunch of random functions and parameters jumbled together. He thinks that it should read more like a human could understand rather than just the machine. With function names like "assertThat" and "hasSelect", it does make it easier to follow.

Patrick Allaert has made this recent post to his blog looking at something that a large group of PHP developers seem to forget about - readable PHP code. Specifically, he mentions the "return as soon as possible" mentality.

This is the first article of a series I will dedicate to tips to write PHP code that is easier to maintain, review, refactor,... These tips may be applied for other languages but are mainly focused on PHP. The first one could be entitled as "return as soon as possible.

He compares a code example - simplifying multiple if/elses, replacing the need for multiple nested evaluations that make the code harder to read. Check out the before and after to see how it helps the flow.

David Otton has a handy little tip if you're looking for a cleaner way to deal with array data - casting it to an object.

Array notation is fine, but it can look a bit clunky when you're working with complex structures. [...] Casting the array to an object allows us to use object notation (->) and makes the code more readable.

He includes examples of the casting, showing the difference between the array and object notations including a method for creating an object based on a simple array that has basic properties built in. This sort of transformation can be useful if you want consistency through out the application - just passing objects with their properties rather than arrays.

Stefan Koopmanschap has a good reminder for developers out there in a new post to his blog - make your code much easier to understand via readable variable names and constants.

Yes, you know what code you write and you also know how it works. You can find your way around it. But what if you haven't touched a piece of code for months or even years. Or what if someone else needs to work with your code. Prevent a hell: use clearly readable variable names and constants.

He points out an example of what not to do - a specific line from the FUDForum code with multiple variables named with a single letter of the alphabet in a complex if() evaluation. He suggests even using "namespacing" of sorts (PHP6 here we come!) to help compartmentalize your variables to make things even easier.

Nick Halstead has posted a few more of his programming tips in the series he's running - three more to be exact dealing with readable code, aggregation, and code structure tips.

• Programming Tips #3 "Divide, Indent, Comment and Name": "We all started programming at some point in our life, some of us on our own, some under guidance of teachers, parents, but even now there are few tips, that should be known by everyone."
• Programming Tips #4 "Aggregation over Inheritance": "My favourite rule is to favour aggregation over inheritance."
• Programming Tips #5 "Readable Code": "It's easier to debug, and later to maintain. Make it readable by using descriptive identifiers, properly tabbing the code, and breaking down the application into functional and reusable pieces."

You can check out the full list of his programming tips in this list.