Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

• the overall style of the code
• the structure of the application (directories, libraries used, etc)
• naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

On PHPMaster.com they've started up a new series focused on refactoring code to make your applications not only easier to maintain but easier to expand on in the future. In this first part they focus on what the term "good code" really means.

The main goal of refactoring is clean code, better code, or whatever you might call it. But what actually constitutes good code? Good code is smelled and tasted. If you’ve written a lot of code, you understand what I mean; you can easily identify whether code is good or bad with experience. But what if you are new to coding but still want to do things right? We can summarize the aspects of good code with these three guidelines: Readable, Extensible and Efficient

He goes on to explain each of these three guidelines with descriptions of what they are and what they mean to you as a developer. In the next part of the series, he'll take these three ideas and apply them to code, showing some of the most common points where they can be applied to clean things up.

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.

In a new post today Patrick Allaert has continued his "Readable Code" series with some tips on how you can make your API handle more.

His suggestions include:

• Changing the handling to look for multiples by default
• Avoiding inner looping (repeated looping) and try for code reuse
• Transforming a scalar value into an array to make it easier to handle this way (by casting)
• and how to handle objects in the same array-handling kind of code

He also tosses in a little mention of performance, noting that a call with range in the argument to his array-handling method is faster than looping over the same range and calling the method each time.

On NETTUTS.com today Burak Guzel has written up some good tips on how to make your code much more readable (and easier to maintain in the future. Not all of them are directly PHP related, but they are general enough to be applied in other places in your development.

Code readability is a universal subject in the world of computer programming. It's one of the first things we learn as developers. Readable and maintainable code is something to be proud of in a finished product. We can share it with others, contribute to other projects, and reuse code from applications we wrote months or even years ago.

Tips included in the list cover topics like:

• comments & documentation
• code grouping
• avoiding deep nesting
• using consistent temporary names
• using object-oriented code versus procedural
• effective refactoring

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

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.

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.