In this new post to his site Vinícius Krolow shares some tips he thinks will help to make your PHP code more readable in the long run.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it's really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

PHPMaster.com has returned with the second part of their guide to code refactoring. In this second part they pick up where they left off and focus on code readability this time.

In part one of this series I introduced what constitutes good code. As the series on code refactoring continues we'll dive into each of the three aspects and see how to refactor for each of them in order: readability, extensibility, and efficiency. In this part, the focus is on refactoring your code for better readability. Recall the definition of readability: readable code follows some well-known style and documentation practices. To help you start refactoring your code for readability, I've prepared this list of questions you should ask yourself throughout the development, testing, and review process.

There's a few different types of things that contribute to readable code, so he breaks the article up into a few sections:

• General things like coding style guides, header comments and a reduction of global code
• Naming conventions, well-named variables and methods
• Simplified and easy to use expressions
• Blocks of code, their average size and complexity.

Volker Dusch has posted what he calls his mandatory templating post comparing the benefits of using plain PHP for templates versus the Twig.

If you read some of my previous posts you know me as a "clean code" guy. I like readable, understandable and maintainable code. The same goes for templates. I need to be able to parse very quickly what is happening.. at least i want to.

He argues that, because the syntax of something like Twig is so much simpler and more readable, it's a better solution in the long run (technical considerations not withstanding). As an example he provides a side by side comparison visual image of the a template for each.

Matthew Weier O'Phinney has a new post today talking about why namespaces in PHP matter and why he thinks they're a valuable contribution to the language.

You've heard about PHP namespaces by now. Most likely, you've heard about -- and likely participated in -- the bikeshedding surrounding the selection of the namespace separator. Regardless of your thoughts on the namespace separator, or how namespaces may or may not work in other languages, I submit to you several reasons for why I think namespaces in PHP are a positive addition to the language.

He breaks down his reasons into four different categories - the code organization benefits that come with namespace "containers", simplified interface structure, improved readability (no more huge class names) and a simpler method for identifying dependencies

Brandon Savage has a recommendation fro developers out there - sometimes readability is more important than any micro-efficiency you might gain in your scripts.

Much was made last week over the topic of micro optimization in PHP. Most of these argued that micro optimization was a bad idea. [...] There's another reason that micro optimization can be a bad choice: it makes code absolutely impossible to read!

He points out one example for validating the length of a string in two ways - one using isset to tell which characters in a string are set and the other using the tride and true call to strlen. The first, while benchmarked to give you a (very tiny) improvements, is harder to read at first glance than the check to the string length.

Shawn Stratton has posted the first part of his series looking at "Code Readability". This part focuses on something that is often woefully forgotten by many developers - proper code commenting.

The simplicity of PHP can sometimes be overwhelming, with so many different ways and approaches to creating solutions for our problems we sometimes lose the ability to think past the current problem and into the future. [...] Today I'm going to try to address some quick ideas that most of you will already be familiar with, things that will aide in the general readability of code for future generations.

He looks at the difference between useful and non-useful comments: DocBlocks, putting them near decisions, listing array parameters, recording TODOs and how it can all help you generate API documentation quickly and easily.

The SitePoint PHP blog has a post that asks developers "Which reference sites do you trust?"

While completing the tech edit on the 2nd edition of the PHP Anthology the issue of linking came up; specifically, linking to authoritative reference material on the web. [...] The issue isn't simple one. Regarding PHP, the php.net manual is the authoritative reference site. The various web technology standards are also represented by authority web sites.

So what does he thing makes for a good, trustworthy resource? He includes criteria divided up into three sections - readability, accuracy & trustworthiness and longevity.